Re: 2.6.17-rc5-mm2

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

>firstly, i'd suggest to use another magic value for 'bottom of call 
>stacks' - it is way too common to jump or call a NULL pointer. Something 
>like 0xfedcba9876543210 would be better.

That's contrary to common use (outside of the kernel). I'm opposed to this. Detecting an initial bad EIP isn't a
problem, and the old code can be used easily in that case.

>for the RIP/EIP to get corrupted is a common occurance. So is stack 
>corruption. So the fallback mechanism shouldnt be a 'short while' 
>side-thought, it must be part of the design.

RIP/EIP corruption, as said above, can be easily handled. RSP/ESP corruption, as I understand it, isn't being handled
in the old code, and so I can't see what improvements the new code could do here (given that instruction and stack
pointers serve as the anchors for kicking off an unwind).

>In all other cases (if we go outside of the stack page(s)) we _must_ 
>fall back to the dump 'scan the stack pages for interesting entries' 
>method, to get the information out! "Uh oh the unwind info somehow got 
>corrupted, sorry" is not enough to debug a kernel bug.

Again, you miss the point that the very last unwind operation must always be expected to move the stack pointer outside
the stack boundaries, which would mean triggering the fallback path in all cases. With this, we could as well leave out
the entire unwind code and keep everyone of us manually do the separation of good and bad entries in the trace shown.

Jan