Messages in this thread | | | Date | Sat, 11 Feb 2012 15:38:09 +0100 | From | Ingo Molnar <> | Subject | Re: [RFC 0/5] kernel: backtrace unwind support |
| |
* 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
| |