Re: [Xen-devel] xen.git branch reorg / success with 2.6.30-rc3 pv_ops dom0

[Ian Campbell <Ian.Campbell@xxxxxxxxxxxxx>]

On Mon, 2009-06-08 at 12:13 -0400, Pasi Kärkkäinen wrote:
> On Mon, Jun 08, 2009 at 05:00:58PM +0100, Ian Campbell wrote:
> > On Mon, 2009-06-08 at 11:45 -0400, Ian Campbell wrote:
> > > 
> > > > L4 at e1822000 is pinned contains L2 at e1977228 which points at an
> > > L1
> > > > which is unpinned low mem address 0x8bf8000
> > > 
> > > OK so I think that is interesting. A pinned L4 referencing an unpinned
> > > L1 isn't supposed to happen, I don't think (Jeremy?).
> > 
> > Interesting:
> > 
> >         pte_t *page_check_address(struct page *page, struct mm_struct *mm,
> >         [...]
> >             pte = pte_offset_map(pmd, address); /* A */
> >             /* Make a quick check before getting the lock */
> >             if (!sync && !pte_present(*pte)) {
> >                     pte_unmap(pte);
> >                     return NULL;
> >             }
> >         
> >             ptl = pte_lockptr(mm, pmd);
> >             spin_lock(ptl);
> >         [...]
> >         
> > So at point A we make a new mapping of a PTE without yet holding the
> > corresponding PTE lock and this is precisely the point at which things
> > start to go wrong for us... (coincidence? I think not ;-))
> > 
> > I wonder how this interacts with the logic in
> > arch/x86/xen/mmu.c:xen_pin_page() which holds the lock while waiting for
> > the (deferred) pin multicall to occur? Hmm, no this is about the
> > PagePinned flag on the struct page which is out of date WRT the actual
> > pinned status as Xen sees it -- we update the PagePinned flag early in
> > xen_pin_page() long before Xen the pin hypercall so this window is the
> > other way round to what would be needed to trigger this bug.
> > 
> > On the other hand xen_unpin_page() looks like it sets up something
> > roughly like what we need for this issue to trigger.
> > 
> > Pasi in additional to my other mad hack could you try this:
> > 
> 
> Ok.. do you want me to try first without this patch? Or should I cancel my
> kernel compilation and apply this aswell? :)

Can you try the first patch first then add this one please.

Ian.

> 
> -- Pasi
> 
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index a5b7781..5663548 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -166,6 +166,7 @@ config SPLIT_PTLOCK_CPUS
> >     int
> >     default "4096" if ARM && !CPU_CACHE_VIPT
> >     default "4096" if PARISC && !PA20
> > +   default "4096" if XEN
> >     default "4"
> >  
> >  #
> > 
> > 
> > Ian.
> > 


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel