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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 22 Dec 2020 20:25:17 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Jonathan Corbet <corbet@....net>, x86-ml <x86@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>
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