Re: [RFC 0/5] kernel: backtrace unwind support

[Ingo Molnar <mingo@elte.hu>]

* Jiri Olsa <jolsa@redhat.com> wrote:

> > I had a quick peek and I don't think it's constructed in a 
> > resilent enough form right now. For example there's no clear 
> > separation and checking of what comes from GCC and what not.
> 
> yes, there's nothing like this in now, I'll see what can be 
> done about that..

Another resilience feature of lockdep is the 'one strike and you 
are out!' aspect: the first error or unexpected condition we 
detect results in the very quick shutting down of all things 
lockdep. It prints exactly one error message, then it 
deactivates and never ever runs again.

The equivalent of this in the scope of your dwarf unwind kernel 
feature would be to fall back to the regular guess and 
framepointer based stack backtrace method the moment any error 
is detected.

Maybe print a single line that indicates that the fallback has 
been activated, and after that the dwarf code should never run 
again. Make sure nobody comes away a "oh, no, the dwarf unwind 
messed up things!' impression, even if it *does* run into some 
trouble (such as unexpected debuginfo generated by GCC - or 
debuginfo *corrupted* by a kernel bug [a very real 
possibility]).

What is totally unacceptable is for the dwarf code to *cause* 
crashes, or to destroy stack trace information.

> yep, looks interesting.. not sure about the mathematical proof 
> though ;)

In the physical sense even mathematics is always and unavoidably 
probability based (or brain and all our senses are 
probabilistic), so you can probably replace 'mathematical proof' 
with 'very robust design and a very, very good track record', 
before bothering Linus with it next time around ;-)

And we might as well conclude "it's simply not worth it", at 
some point down he road. I *do* think that it's worth it though, 
and I do think it can be designed and implemented robustly, so 
I'd be willing to try out these patches in -tip for a kernel 
release or two, without pushing it to Linus.

Thanks,

	Ingo