Re: [Xen-devel] vmalloc_sync_all crash still happening on some machines

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Tue, 2011-12-20 at 16:51 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [Xen-devel] vmalloc_sync_all crash still happening 
> on some machines"):
> > More specifically it seems to be
> > 6bec8b4a4c14095d0b7ce424db9d583c3decae6c from Jeremy's xen/next-2.6.32
> > branch.
> 
> My script is still pulling from Jeremy's github.  I see that the tree
> on git.kernel.org has many new changesets so I'll switch back to that.
> I guess I naively assumed that having established two trees Jeremy
> might push to both of them...
> 
> > I suspect that's a red-herring though since I bet the vmalloc fixes
> > simply never got backported to this tree.
> 
> Yes, it looks like they didn't.

Looking at the tree the vmalloc_sync_all() in alloc_vm_area() is present
and has been for ages. The upstream stuff I was thinking of was David
Vrabel's work to make the sync unnecessary.

The only difference in vmalloc_sync_all seems to be that 2.6.32 uses
spin_lock_irqsave() while upstream uses just spin_lock() which doesn't
seem likely to make a difference.

The actual bug you are seeing is hitting the                 
        BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k))
towards the end of vmalloc_sync_one(). David, do you remember from when
you were digging into this stuff what it actually means?

I suppose we could backport the stuff to make vmalloc_sync_all
unnecessary, but I guess there'd be no guarantee it would help since the
root cause isn't really understood.

Ian.



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