Messages in this thread | | | Date | Tue, 22 Dec 2020 20:25:17 +0100 | From | Borislav Petkov <> | Subject | Re: [PATCH] Documentation/submitting-patches: Add blurb about backtraces in commit messages |
| |
On Tue, Dec 22, 2020 at 10:59:22AM -0800, Sean Christopherson wrote: > On Tue, Dec 22, 2020, Borislav Petkov wrote: > > Ok, here's the next one which I think, is also, not really controversial. > > Heh, are you trying to jinx yourself?
I was trying to conjure up some bikeshedding... and there it is! :-)
> > +Backtraces help document the call chain leading to a problem. However, > > +not all backtraces are helpful. For example, early boot call chains are > > +unique and obvious. > > I'd argue that there is still value in the backtrace though, e.g. I find them > very helpful when doing git archaeology. A backtrace is an easily recognizable > signature (don't have to read a bunch of text to understand there was a splat of > some kind), and the call stack is often helpful even if it is unique, e.g. for > unfamiliar code (including early boot chains) and/or code that is substantially > different from the current upstream.
I think the intent of the text is to say not to include callchains which are *really* obvious. As in, there's no ambiguity as to how one has landed here.
Also, sometimes people paste backtraces from a WARN* which are almost always superfluous - only the warn's address is important. This is at least how I go about debugging those.
Maybe the text should be made more precise.
> I'd prefer not to encourage people to strip the info after the function name, > though I do agree it's somewhat distracting (especially the offset/size).
Yes. Especially since they don't make any sense on another system or even on the same system but with a different .config.
> The module, call site in the function, exact file/line if available, > etc... provides context that I find helpful for building a mental > model of what went wrong.
File/line is more useful, yes, but only for the current code snapshot. When time passes and stuff gets changed, those file/line things are not correct anymore so one would have to checkout the tree on which the splat happened.
I guess I need to make that aspect more precise too.
> E.g. which modules are in play, which short wrapper functions can > likely be glossed over, etc...
That example doesn't have modules. I guess I'll generate a new one.
Thx.
-- Regards/Gruss, Boris.
https://people.kernel.org/tglx/notes-about-netiquette
| |