[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [BUG] double fault for sale ;)
> > On 30 May 2006, at 15:02, Gerd Hoffmann wrote: > > >> The few stack frames you looked at already look quite innocent. They > >> don't take up much stack space. OTOH it is somewhat weird to be doing > >> writable pagetable work that far down the stack. It'll be interesting > >> to > >> see what was going on to cause writable pagetable state to be flushed. > > > > Looks like an endless recursion, trace (and patch) attached. > > Looks like writable pagetable logic gets tangled up somehow. I'll look > into it. Gerd, Can you please let me know whether the attached patch fixes the crash for you? I suspect a bug in your modified builder triggered a broken error path in Xen -- so this patch will hopefully turn the Xen crash into a failure of your modified builder. :-) -- Keir diff -r e58e04589d11 xen/arch/x86/mm.c --- a/xen/arch/x86/mm.c Tue May 30 12:29:29 2006 +++ b/xen/arch/x86/mm.c Tue May 30 15:42:02 2006 @@ -1598,12 +1598,18 @@ { if ( unlikely((x & PGT_type_mask) != (type & PGT_type_mask) ) ) { - if ( current->domain == page_get_owner(page) ) + if ( (current->domain == page_get_owner(page)) && + ((x & PGT_type_mask) == PGT_writable_page) ) { /* * This ensures functions like set_gdt() see up-to-date * type info without needing to clean up writable p.t. - * state on the fast path. + * state on the fast path. We take this path only + * when the current type is writable because: + * 1. It's the only type that this path can decrement. + * 2. If we take this path more liberally then we can + * enter a recursive loop via get_page_from_l1e() + * during pagetable revalidation. */ LOCK_BIGLOCK(current->domain); cleanup_writable_pagetable(current->domain); _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxxxxxxxx http://lists.xensource.com/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |