Re: [PATCH] Documentation/submitting-patches: Add blurb about backtraces in commit messages

From: Borislav Petkov <bp@alien8.de>
To: Sean Christopherson <seanjc@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>, x86-ml <x86@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Documentation/submitting-patches: Add blurb about backtraces in commit messages
Date: Tue, 22 Dec 2020 20:25:17 +0100	[thread overview]
Message-ID: <20201222192517.GE13463@zn.tnic> (raw)
In-Reply-To: <X+JCCqTJkgZASj7T@google.com>

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