>
> 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