Re: 2.6.17-rc2-mm1

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

>> ><EOE>new stack 0 (0 0 0 10082 10)
>> 
>> Looks like <rubbish> <SS> <RSP> <RFLAGS> <CS> to me, ...
>
>Hmm, right.
> 
>> >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.
>
>Any can you add that please and check? 

???

>Also worst case one could dump last branch pointers. AMD unfortunately only has four,
>on Intel with 16 it's easier.

Provided you disable recording early enough. Otherwise only one (last exception from/to) is going to be useful on
both.

>I can provide a patch for that if needed.
>
>> 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. 
>
>Yes it probably should check for that.
>
>> 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.
>
>That can cause recursive exceptions. I'm a bit paranoid with that.

Without doing so it can also cause recursive exceptions, just that this is going to be deadly then.

Jan