linux-kernel - Re: [GIT PULL] more printk for 6.15

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]

Message-ID: <Z-2XVMOJXUjVYXV0@google.com>
Date: Wed, 2 Apr 2025 13:00:20 -0700
From: Sean Christopherson <seanjc@...gle.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>, Petr Mladek <pmladek@...e.com>, 
	Sergey Senozhatsky <senozhatsky@...omium.org>, Steven Rostedt <rostedt@...dmis.org>, 
	John Ogness <john.ogness@...utronix.de>, 
	Andy Shevchenko <andriy.shevchenko@...ux.intel.com>, 
	Rasmus Villemoes <linux@...musvillemoes.dk>, Peter Zijlstra <peterz@...radead.org>, 
	linux-kernel@...r.kernel.org
Subject: Re: [GIT PULL] more printk for 6.15

On Wed, Apr 02, 2025, Linus Torvalds wrote:
> On Wed, 2 Apr 2025 at 12:07, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > The whole "link to original submission" is garbage.
> 
> Just to clarify: people should link to the *problem* report. Or to the
> *debugging* thread.
> 
> But linking to the final result is pointless. That's what in the tree,
> and any subsequent discussion about it is stale and late.

It's not pointless noise to everyone.

For people that come across the commit after the fact, which may be years down
the road, e.g. when doing git archaeology, having an explicit link to *something*
is extremely valuable.  The final submission may not have the full context, but
more often than not there are links and references to threads that do provide
additional context.  At the very least, it's a starting point for the hunt.

"just Google it" does work most of the time, but search engines won't help all
that much if the maintainer massaged the shortlog and/or changelog, especially
if the surgery done when applying is significant.  And if the source patch was
never posted to a public list, lack of a source Link is a hint that trying to
find the source/context may be futile.

Linking to source of the commit also provides a paper trail that can be used to
audit the final result.  As a maintainer, I've used the link to verify that I
actually applied the version I intended to apply.

E.g. with zero a priori knowledge of the situation, it was trivially easy for me
to verify that Thomas' goof[*] with the irq/msi series was due to v2 getting
applied instead of v4, thanks to the Links in the buggy commits.

I can appreciate that in your role, a Link to the source patch is a false positive
more often than not.  But isn't that a problem with the tag being ambiguous?  I
assume it's not the mere presense of the line in the changelog that's most
frustrating, it's the wasted time and crushing disappointment of following the
link and finding nothing useful.

So rather than trash the convention entirely and risk throwing out the baby with
the bath water, what if we tweak the convention to use a dedicated tag, a la
Closes?  E.g. Source or something.  If b4 implements the new tag, it shouldn't be
too hard to get maintainers to follow suit.  Then you can quickly gloss over the
tag and mutter about its uselessness as you do so, and us plebs can continue
reveling in the joy of our source links.

[*] https://lkml.kernel.org/r/20250319104921.201434198%40linutronix.de