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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

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:

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