WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

RE: [Xen-devel] [memory sharing] bug on get_page_and_type

Hi Tim:
 
      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?
 
     2) Could we improve p2m_lock to sparse lock, which maybe better, right? 
 
     thanks.
 
> 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 hav e the
> callers of p2m code touching the p2m lock directly so we may need a new
> p2m interface to address it.
>
> Tim.
>
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel