At 02:46 +0000 on 09 Feb (1297219562), MaoXiaoyun wrote:
> I've been looking into the TOCTOU issue quite a while, but
>
> 1) There are quite a lot judgements like "p2m_is_shared(p2mt)" or
> "p2mt == p2m_ram_shared", which, for me, is hard to tell whom
> are need to be protect by p2m_lock and whom are not So is
> there a rule to distinguish these?
Not particularly. I suspect that most of them will need to be
changed, but as I said I hope we can find something nicer than
scattering p2m_lock() around non-p2m code.
> 2) Could we improve p2m_lock to sparse lock, which maybe better, right?
Maybe, but not necessarily. Let's get it working properly first and
then we can measure lock contention and see whether fancy locks are
worthwhile.
Tim.
>
> > Date: Wed, 2 Feb 2011 16:18:37 +0000
> > From: Tim.Deegan@xxxxxxxxxx
> > To: tinnycloud@xxxxxxxxxxx
> > CC: xen-devel@xxxxxxxxxxxxxxxxxxx; George.Dunlap@xxxxxxxxxxxxx;
> > juihaochiang@xxxxxxxxx
> > Subject: Re: [Xen-devel] [memory sharing] bug on get_page_and_type
> >
> > At 15:43 +0000 on 02 Feb (1296661396), MaoXiaoyun wrote:
> > > Hi Tim:
> > >
> > > Thanks for both your advice and quick reply. I will follow.
> > >
> > > So at last we should replace shr_lock with p2m_lock.
> > > But more complicate, it seems both the
> > > *check action* code and *nominate page* code need to be locked ,right?
> > > If so, quite a lot of *check action* codes need to be locked.
> >
> > Yes, I think you're right about that. Unfortunately there are some very
> > long TOCTOU windows in those kind of p2m lookups, which will get more
> > important as the p2m gets more dynamic. I don't want to have the
> > callers of p2m code touching the p2m lock directly so we may need a new
> > p2m interface to address it.
> >
> > Tim.
> >
--
Tim Deegan <Tim.Deegan@xxxxxxxxxx>
Principal Software Engineer, Xen Platform Team
Citrix Systems UK Ltd. (Company #02937203, SL9 0BG)
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|