Re: 2.6.17-rc2-mm1

["Jan Beulich" <jbeulich@novell.com>]

>>> Andi Kleen <ak@suse.de> 02.05.06 22:09 >>>
>On Tuesday 02 May 2006 22:00, Martin Bligh wrote:
>
>> > Index: linux/arch/x86_64/kernel/traps.c
>> > ===================================================================
>> > --- linux.orig/arch/x86_64/kernel/traps.c
>> > +++ linux/arch/x86_64/kernel/traps.c
>> > @@ -238,6 +238,7 @@ void show_trace(unsigned long *stack)
>> >  			HANDLE_STACK (stack < estack_end);
>> >  			i += printk(" <EOE>");
>> >  			stack = (unsigned long *) estack_end[-2];
>> > +			printk("new stack %lx (%lx %lx %lx %lx %lx)\n", stack, estack_end[0], estack_end[-1],
estack_end[-2], estack_end[-3], estack_end[-4]);
>> >  			continue;
>> >  		}
>> >  		if (irqstack_end) {
>> 
>> Thanks for running this Andy:
>> 
>> http://test.kernel.org/abat/30183/debug/console.log 
>
>
><EOE>new stack 0 (0 0 0 10082 10)

Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...

>Hmm weird. There isn't anything resembling an exception frame at the top of the
>stack.  No idea how this could happen.

... which is a valid frame where the stack pointer was corrupted before the exception occurred. One more printed item
(or rather, starting items at estack_end[-1]) would allow at least seeing what RIP this came from.

This actually points out another weakness of that code: if you pick up a mis-aligned stack pointer then the conditions
in both the exception and interrupt stack invocations of HANDLE_STACK() won't prevent you from accessing an item
crossing a page boundary, and hence potentially faulting. Similarly, obtaining an entirely bad stack pointer anywhere in
that code will result in a fault. I guess the stack reads should really be done using get_user() or some other code
having recovery attached.

Jan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/