[BUG] double fault for sale ;)

[BUG] double fault for sale ;)

[Gerd Hoffmann]

  Hi folks,

I'm busy rewriting the domain builder code a bit, to restruct the code
and make it better usable for other tasks than directly booting a
domain.  While testing these bits I trapped into that one:

(XEN) CPU:    1
(XEN) EIP:    e008:[<ff137512>] get_page_type+0x12/0x63d
(XEN) EFLAGS: 00010296
(XEN) CR3:    00000000
(XEN) eax: 33030001   ebx: ff1c1080   ecx: ff1d4080   edx: ff1d4080
(XEN) esi: 0000001a   edi: ffbf5fac   ebp: ffbf502c   esp: ffbf4f84
(XEN) ds: e010   es: e010   fs: 0000   gs: 0000   ss: e010
(XEN) ************************************
(XEN) CPU1 DOUBLE FAULT -- system shutdown
(XEN) System needs manual reset.
(XEN) ************************************

I think even Domain-0 shouldn't be able to crash xen like this, no?

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

Re: [BUG] double fault for sale ;)

[Keir Fraser]

On 29 May 2006, at 16:00, Gerd Hoffmann wrote:

> I'm busy rewriting the domain builder code a bit, to restruct the code
> and make it better usable for other tasks than directly booting a
> domain.  While testing these bits I trapped into that one:
>
> (XEN) CPU:    1
> (XEN) EIP:    e008:[<ff137512>] get_page_type+0x12/0x63d
> (XEN) EFLAGS: 00010296
> (XEN) CR3:    00000000
> (XEN) eax: 33030001   ebx: ff1c1080   ecx: ff1d4080   edx: ff1d4080
> (XEN) esi: 0000001a   edi: ffbf5fac   ebp: ffbf502c   esp: ffbf4f84
> (XEN) ds: e010   es: e010   fs: 0000   gs: 0000   ss: e010
> (XEN) ************************************
> (XEN) CPU1 DOUBLE FAULT -- system shutdown
> (XEN) System needs manual reset.
> (XEN) ************************************
>
> I think even Domain-0 shouldn't be able to crash xen like this, no?

Looks like a stack overflow, since the stack pointer is in an "even" 
page which is guard page when running a debug build of Xen. Maybe you 
could hack up some code to get a rough back trace (round the crashing 
stack pointer up to a page boundary then scan a whole page for text 
addresses)?

Either need to fix some large stack frame or make the stack larger. 
Probably the former.

  -- Keir

Re: [BUG] double fault for sale ;)

[Jan Beulich]

Looks suspiciously like a stack overflow (comparing esp and ebp) - did you perhaps add (for debugging) some large stack
objects somewhere? Unfortunately the code isn't clever enough to provide a stack trace in such a situation... Jan

>>> Gerd Hoffmann <kraxel@suse.de> 29.05.06 17:00 >>>
Hi folks,

I'm busy rewriting the domain builder code a bit, to restruct the code
and make it better usable for other tasks than directly booting a
domain.  While testing these bits I trapped into that one:

(XEN) CPU:    1
(XEN) EIP:    e008:[<ff137512>] get_page_type+0x12/0x63d
(XEN) EFLAGS: 00010296
(XEN) CR3:    00000000
(XEN) eax: 33030001   ebx: ff1c1080   ecx: ff1d4080   edx: ff1d4080
(XEN) esi: 0000001a   edi: ffbf5fac   ebp: ffbf502c   esp: ffbf4f84
(XEN) ds: e010   es: e010   fs: 0000   gs: 0000   ss: e010
(XEN) ************************************
(XEN) CPU1 DOUBLE FAULT -- system shutdown
(XEN) System needs manual reset.
(XEN) ************************************

I think even Domain-0 shouldn't be able to crash xen like this, no?

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg 

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

Re: [BUG] double fault for sale ;)

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

> Looks like a stack overflow, since the stack pointer is in an "even"
> page which is guard page when running a debug build of Xen. Maybe you
> could hack up some code to get a rough back trace (round the crashing
> stack pointer up to a page boundary then scan a whole page for text
> addresses)?

Done, see attachments for results if someone wants have a quick look,
I'll continue debugging tomorrow.

Nice guess btw, it really is a debug build ;)

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

[-- Attachment #2: xen-double-fault-2 --]
[-- Type: text/plain, Size: 2139 bytes --]

(XEN) CPU:    1
(XEN) EIP:    e008:[<ff137512>] get_page_type+0x12/0x63d
(XEN) EFLAGS: 00010296
(XEN) CR3:    00000000
(XEN) eax: 33030001   ebx: ff1c1080   ecx: ff1d4080   edx: ff1d4080
(XEN) esi: 0000001a   edi: ffbf5fac   ebp: ffbf502c   esp: ffbf4f84
(XEN) ds: e010   es: e010   fs: 0000   gs: 0000   ss: e010
(XEN) Xen stack trace from esp=ffbf4f84:
(XEN)   stack overflow fixup
(XEN) Xen stack trace from esp=ffbf5000:
(XEN)    00000001 00000000 00000000 8000000b 8000000c 8000000b ff1d4080 ff1d4080
(XEN)    ff1c1080 0000001a ffbf5fac ffbf504c ff135035 fc418ca8 e0000000 ffbf50ac
(XEN)    00000286 00000000 00000001 ffbf509c ff135a93 fc418ca8 ff1d4080 e0000000
(XEN)    00000096 00000096 00000097 00000286 00000096 00000000 ff1c1080 ffbf50dc
(XEN)    ff183b28 00001087 fc418ca8 00000000 ff1c1080 0000001a ffbf5fac ffbf50dc
(XEN)    ff13c80e 01087063 ff1d4080 ffbf50dc 00000000 ff1c1080 ff1d4480 ff1d4698
(XEN)    01087063 00000000 00000001 00000347 00000000 3d016000 ff1c1080 ffbf511c
(XEN)    ff13cb13 ff1d4080 fec0a000 ff1c3000 00000000 00000000 012b3061 c0007d1d
(XEN)    fec0a000 fe30001c 00000000 00000000 00000000 00000000 ff1c1080 ffbf512c
(XEN)    ff13d89f ff1d4080 00000000 ffbf51dc ff137766 ff1d4080 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000000 00000000 00000000 00000000 33030002
(XEN)    33030001 33030001 00000000 00000001 00000000 00000000 00000000 00000000
(XEN)    00000000 00000000 00000000 00000001 00000000 00000000 8000000a
(XEN)    ff135035 fc418ca8 e0000000 ffbf525c 00000282 00000000 00000001 ffbf524c
(XEN)    ff135a93 fc418ca8 ff1d4080 e0000000 00000095 00000095 00000096 00000282
(XEN)    00000095 00000000 ff1c1080 ffbf528c ff183b28 00001087 fc418ca8 00000000
(XEN)    ff1c1080 0000001a ffbf5fac ffbf528c ff13c80e 01087063 ff1d4080 ffbf528c
(XEN)    00000000 ff1c1080 ff1d4480 ff1d4698 01087063 00000000 00000001 00000347
(XEN) ************************************
(XEN) CPU1 DOUBLE FAULT -- system shutdown
(XEN) System needs manual reset.
(XEN) ************************************
+ xm destroy ttylinux

[-- Attachment #3: xen-double-fault-2-sym --]
[-- Type: text/plain, Size: 688 bytes --]

ff135001 <get_page_and_type>:
ff135035:	85 c0                	test   %eax,%eax
--
ff135917 <get_page_from_l1e>:
ff135a93:	89 45 e0             	mov    %eax,0xffffffe0(%ebp)
--
ff137500 <get_page_type>:
ff137766:	8b 45 08             	mov    0x8(%ebp),%eax
--
ff13c75c <revalidate_l1>:
ff13c80e:	85 c0                	test   %eax,%eax
ff13c8db <ptwr_flush>:
ff13cb13:	89 45 f0             	mov    %eax,0xfffffff0(%ebp)
--
ff13d83b <cleanup_writable_pagetable>:
ff13d88a:	74 13                	je     ff13d89f <cleanup_writable_pagetable+0x64>
ff13d89f:	8b 45 08             	mov    0x8(%ebp),%eax
--
ff183ac0 <map_domain_page>:
ff183b28:	89 45 d8             	mov    %eax,0xffffffd8(%ebp)

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

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

Re: [BUG] double fault for sale ;)

[Keir Fraser]

On 29 May 2006, at 17:03, Gerd Hoffmann wrote:

> Done, see attachments for results if someone wants have a quick look,
> I'll continue debugging tomorrow.

You also want to take each stack value that is between _text and _end 
labels and call print_symbol() on it. That will give you a better 
impression of the backtrace quickly. If you also print the stack delta 
between each value that you pass to print_symbol() you'll also see 
which are the stack frames that are really troublesome.

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.

  -- Keir

> Nice guess btw, it really is a debug build ;)

Re: [BUG] double fault for sale ;)

[Gerd Hoffmann]

[-- Attachment #1: Type: text/plain, Size: 469 bytes --]

Keir Fraser 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.

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg

[-- Attachment #2: xen-double-fault-3-stack --]
[-- Type: text/plain, Size: 6210 bytes --]

(XEN) Xen stack trace from esp=ffbf4f84:
(XEN)   stack overflow fixup
(XEN) Xen stack trace from esp=ffbf5000:
(XEN)  stack ffbf5030, text ff135035 <get_page_and_type+0x34/0x57>
(XEN)  stack ffbf5050, text ff135a93 <get_page_from_l1e+0x17c/0x206>, frame 8
(XEN)  stack ffbf5080, text ff183b28 <map_domain_page+0x68/0x3fa>, frame 12
(XEN)  stack ffbf50a0, text ff13c80e <revalidate_l1+0xb2/0x17f>, frame 8
(XEN)  stack ffbf50e0, text ff13cb13 <ptwr_flush+0x238/0x34f>, frame 16
(XEN)  stack ffbf5120, text ff13d89f <cleanup_writable_pagetable+0x64/0x86>, frame 16
(XEN)  stack ffbf5130, text ff137766 <get_page_type+0x266/0x63d>, frame 4
(XEN)  stack ffbf51e0, text ff135035 <get_page_and_type+0x34/0x57>, frame 44
(XEN)  stack ffbf5200, text ff135a93 <get_page_from_l1e+0x17c/0x206>, frame 8
(XEN)  stack ffbf5230, text ff183b28 <map_domain_page+0x68/0x3fa>, frame 12
(XEN)  stack ffbf5250, text ff13c80e <revalidate_l1+0xb2/0x17f>, frame 8
(XEN)  stack ffbf5290, text ff13cb13 <ptwr_flush+0x238/0x34f>, frame 16
(XEN)  stack ffbf52d0, text ff13d89f <cleanup_writable_pagetable+0x64/0x86>, frame 16
(XEN)  stack ffbf52e0, text ff137766 <get_page_type+0x266/0x63d>, frame 4
(XEN)  stack ffbf5390, text ff135035 <get_page_and_type+0x34/0x57>, frame 44
(XEN)  stack ffbf53b0, text ff135a93 <get_page_from_l1e+0x17c/0x206>, frame 8
(XEN)  stack ffbf53e0, text ff183b28 <map_domain_page+0x68/0x3fa>, frame 12
(XEN)  stack ffbf5400, text ff13c80e <revalidate_l1+0xb2/0x17f>, frame 8
(XEN)  stack ffbf5440, text ff13cb13 <ptwr_flush+0x238/0x34f>, frame 16
(XEN)  stack ffbf5480, text ff13d89f <cleanup_writable_pagetable+0x64/0x86>, frame 16
(XEN)  stack ffbf5490, text ff137766 <get_page_type+0x266/0x63d>, frame 4
(XEN)  stack ffbf5540, text ff135035 <get_page_and_type+0x34/0x57>, frame 44
(XEN)  stack ffbf5560, text ff135a93 <get_page_from_l1e+0x17c/0x206>, frame 8
(XEN)  stack ffbf5590, text ff183b28 <map_domain_page+0x68/0x3fa>, frame 12
(XEN)  stack ffbf55b0, text ff13c80e <revalidate_l1+0xb2/0x17f>, frame 8
(XEN)  stack ffbf55f0, text ff13cb13 <ptwr_flush+0x238/0x34f>, frame 16
(XEN)  stack ffbf5630, text ff13d89f <cleanup_writable_pagetable+0x64/0x86>, frame 16
(XEN)  stack ffbf5640, text ff137766 <get_page_type+0x266/0x63d>, frame 4
(XEN)  stack ffbf56f0, text ff135035 <get_page_and_type+0x34/0x57>, frame 44
(XEN)  stack ffbf5710, text ff135a93 <get_page_from_l1e+0x17c/0x206>, frame 8
(XEN)  stack ffbf5740, text ff183b28 <map_domain_page+0x68/0x3fa>, frame 12
(XEN)  stack ffbf5760, text ff13c80e <revalidate_l1+0xb2/0x17f>, frame 8
(XEN)  stack ffbf57a0, text ff13cb13 <ptwr_flush+0x238/0x34f>, frame 16
(XEN)  stack ffbf57e0, text ff13d89f <cleanup_writable_pagetable+0x64/0x86>, frame 16
(XEN)  stack ffbf57f0, text ff137766 <get_page_type+0x266/0x63d>, frame 4
(XEN)  stack ffbf58a0, text ff135035 <get_page_and_type+0x34/0x57>, frame 44
(XEN)  stack ffbf58c0, text ff135a93 <get_page_from_l1e+0x17c/0x206>, frame 8
(XEN)  stack ffbf58f0, text ff183b28 <map_domain_page+0x68/0x3fa>, frame 12
(XEN)  stack ffbf5910, text ff13c80e <revalidate_l1+0xb2/0x17f>, frame 8
(XEN)  stack ffbf5950, text ff13cb13 <ptwr_flush+0x238/0x34f>, frame 16
(XEN)  stack ffbf597c, text ff137b63 <__cpus_empty+0x18/0x1a>, frame 11
(XEN)  stack ffbf5990, text ff13d89f <cleanup_writable_pagetable+0x64/0x86>, frame 5
(XEN)  stack ffbf59a0, text ff137766 <get_page_type+0x266/0x63d>, frame 4
(XEN)  stack ffbf59cc, text ff1233f5 <smp_apic_timer_interrupt+0x17/0x19>, frame 11
(XEN)  stack ffbf5a1c, text ff183f8e <mapcache_current_vcpu+0xb/0xc5>, frame 20
(XEN)  stack ffbf5a50, text ff135035 <get_page_and_type+0x34/0x57>, frame 13
(XEN)  stack ffbf5a70, text ff135a93 <get_page_from_l1e+0x17c/0x206>, frame 8
(XEN)  stack ffbf5aa0, text ff183b28 <map_domain_page+0x68/0x3fa>, frame 12
(XEN)  stack ffbf5aac, text ff13d1e7 <ptwr_emulated_update+0x5bd/0x5d6>, frame 3
(XEN)  stack ffbf5ac0, text ff13c80e <revalidate_l1+0xb2/0x17f>, frame 5
(XEN)  stack ffbf5b00, text ff13cb13 <ptwr_flush+0x238/0x34f>, frame 16
(XEN)  stack ffbf5b40, text ff13d89f <cleanup_writable_pagetable+0x64/0x86>, frame 16
(XEN)  stack ffbf5b50, text ff137766 <get_page_type+0x266/0x63d>, frame 4
(XEN)  stack ffbf5b70, text ff183f8e <mapcache_current_vcpu+0xb/0xc5>, frame 8
(XEN)  stack ffbf5b80, text ff183e85 <map_domain_page+0x3c5/0x3fa>, frame 4
(XEN)  stack ffbf5c00, text ff135035 <get_page_and_type+0x34/0x57>, frame 32
(XEN)  stack ffbf5c20, text ff135a93 <get_page_from_l1e+0x17c/0x206>, frame 8
(XEN)  stack ffbf5c50, text ff183b28 <map_domain_page+0x68/0x3fa>, frame 12
(XEN)  stack ffbf5c70, text ff13c80e <revalidate_l1+0xb2/0x17f>, frame 8
(XEN)  stack ffbf5cb0, text ff13cb13 <ptwr_flush+0x238/0x34f>, frame 16
(XEN)  stack ffbf5cc0, text ff135637 <get_page_from_pagenr+0x43/0x93>, frame 4
(XEN)  stack ffbf5cf0, text ff13d89f <cleanup_writable_pagetable+0x64/0x86>, frame 12
(XEN)  stack ffbf5d00, text ff137766 <get_page_type+0x266/0x63d>, frame 4
(XEN)  stack ffbf5d10, text ff12341c <raise_softirq+0x25/0x27>, frame 4
(XEN)  stack ffbf5d20, text ff135c12 <get_page_from_l2e+0xf5/0x131>, frame 4
(XEN)  stack ffbf5d30, text ff137c01 <__next_cpu+0x26/0x48>, frame 4
(XEN)  stack ffbf5db0, text ff135035 <get_page_and_type+0x34/0x57>, frame 32
(XEN)  stack ffbf5dd0, text ff135a93 <get_page_from_l1e+0x17c/0x206>, frame 8
(XEN)  stack ffbf5e00, text ff183b28 <map_domain_page+0x68/0x3fa>, frame 12
(XEN)  stack ffbf5e20, text ff13c80e <revalidate_l1+0xb2/0x17f>, frame 8
(XEN)  stack ffbf5e60, text ff13cb13 <ptwr_flush+0x238/0x34f>, frame 16
(XEN)  stack ffbf5e70, text ff138731 <set_foreigndom+0x13/0x228>, frame 4
(XEN)  stack ffbf5e8c, text ff184169 <unmap_domain_page+0x107/0x33c>, frame 7
(XEN)  stack ffbf5ea0, text ff13d89f <cleanup_writable_pagetable+0x64/0x86>, frame 5
(XEN)  stack ffbf5eb0, text ff1389df <do_mmuext_op+0x99/0xa2f>, frame 4
(XEN)  stack ffbf5ecc, text ff13d5e6 <ptwr_do_page_fault+0x37b/0x483>, frame 7
(XEN)  stack ffbf5f3c, text ff144dba <fixup_page_fault+0x39e/0x3ec>, frame 28
(XEN)  stack ffbf5f6c, text ff144fe1 <do_page_fault+0x9f/0x334>, frame 12
(XEN)  stack ffbf5f80, text ff11c5f5 <do_softirq+0xa1/0xb8>, frame 5
(XEN)  stack ffbf5f90, text ff1847df <hypercall+0x8f/0xaf>, frame 4

[-- Attachment #3: xen-debug-patch --]
[-- Type: text/plain, Size: 1481 bytes --]

diff -r 14717dedba02 xen/arch/x86/x86_32/traps.c
--- a/xen/arch/x86/x86_32/traps.c	Sun May 21 19:15:58 2006
+++ b/xen/arch/x86/x86_32/traps.c	Tue May 30 15:59:30 2006
@@ -173,6 +173,51 @@
            tss->esi, tss->edi, tss->ebp, tss->esp);
     printk("ds: %04x   es: %04x   fs: %04x   gs: %04x   ss: %04x\n",
            tss->ds, tss->es, tss->fs, tss->gs, tss->ss);
+
+    {
+#define stack_words_per_line  8
+
+	unsigned long *stack, addr, *lstack;
+	int words;
+
+	addr = tss->esp;
+	stack = (void*)addr;
+	printk("Xen stack trace from "__OP"sp=%p:\n  ", stack);
+
+	if ((addr & 0xfff) > 0xf00) {
+		printk("stack overflow fixup\n");
+		while ((addr & 0xfff) > 0xf00)
+			addr += 4;
+		stack = (void*)addr;
+		printk("Xen stack trace from "__OP"sp=%p:\n  ", stack);
+	}
+
+	lstack = NULL;
+	for (;; stack++) {
+	    if (((long)stack & (STACK_SIZE-BYTES_PER_LONG)) == 0)
+		break;
+	    addr = *stack;
+	    if (is_kernel_text(addr)) {
+		printk("\n stack %p, text %p <", stack, _p(addr));
+		print_symbol("%s",addr);
+		printk(">");
+		if (lstack)
+			printk(", frame %d", stack - lstack);
+		lstack = stack;
+		printk("\n");
+		words = 0;
+	    } else {
+		if (stack_words_per_line == words) {
+		    printk("\n");
+		    words = 0;
+		}
+		printk(" %p", _p(addr));
+		words++;
+	    }
+	}
+	printk("\n");
+    }
+
     printk("************************************\n");
     printk("CPU%d DOUBLE FAULT -- system shutdown\n", cpu);
     printk("System needs manual reset.\n");

[-- Attachment #4: Type: text/plain, Size: 138 bytes --]

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

Re: [BUG] double fault for sale ;)

[Keir Fraser]

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.

  -- Keir

Re: [BUG] double fault for sale ;)

[Keir Fraser]

[-- Attachment #1: Type: text/plain, Size: 793 bytes --]

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


[-- Attachment #2: wrpt_recursion.patch --]
[-- Type: text/plain, Size: 1354 bytes --]

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

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [BUG] double fault for sale ;)

[Gerd Hoffmann]

> 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. :-)

Yep, its fixed, now the newly created domain crashes, probably during
kernels initial page table setup (pfn 0 looks like that), which likely
is a builder bug.

I get this now:

(XEN) DOM1: (file=mm.c, line=1528) Bad type (saw 33030001 != exp
e0000000) for mfn c72 (pfn 0)
(XEN) DOM1: (file=mm.c, line=505) Error getting mfn c72 (pfn 0) from L1
entry 00c72063 for dom1
(XEN) DOM1: (file=mm.c, line=3054) ptwr: Could not revalidate l1 page
(XEN) domain_crash called from mm.c:3055
(XEN) Domain 1 (vcpu#0) crashed on cpu#1:
(XEN) ----[ Xen-3.0-unstable    Not tainted ]----
(XEN) CPU:    1
(XEN) EIP:    e019:[<c0101347>]
(XEN) EFLAGS: 00000286   CONTEXT: guest
[ ... ]

cheers,

  Gerd

-- 
Gerd Hoffmann <kraxel@suse.de>
http://www.suse.de/~kraxel/julika-dora.jpeg