Re: [GIT PULL] io_uring fix for 6.17-rc5

[Alexei Starovoitov <alexei.starovoitov@gmail.com>]

On Fri, Sep 05, 2025 at 06:01:01PM -0600, Jens Axboe wrote:
> On 9/5/25 2:54 PM, Linus Torvalds wrote:
> > On Fri, 5 Sept 2025 at 12:30, Jens Axboe <axboe@kernel.dk> wrote:
> >>
> >> Like I said, I think there more fruitful ways to get the point across
> >> and this picked up and well known, because I don't believe it is right
> >> now.
> > 
> > So I've actually been complaining about the link tags for years: [1]
> > [2] [3] [4].
> > 
> > In fact, that [4] from 2022 is about how people are then trying to
> > distinguish the *useful* links (to bug reports) from the useless ones,
> > by giving them a different name ("Buglink:"). Where I was telling
> > people to instead fix this problem by just not adding the useless
> > links in the first place!
> > 
> > Anyway, I'm a bit frustrated, exactly because this _has_ been going on
> > for years. It's not a new peeve.
> 
> What's that saying on doing the same thing over and over again and
> expecting different results...? :-)
> 
> > And I don't think we have a good central place for that kind of "don't do this".
> > 
> > Yes, there's the maintainer summit, but that's a pretty limited set of people.
> 
> That'd be a great place to discuss it, however. One thing I've always
> wanted to bring up but have forgotten to, is how I'd _love_ for your PR
> merges to contain the link to the PR that you got for them. Yes I know
> that's now adding a link, but that's a useful one. Maybe not for you,
> but for me and I bet tons of other people. At least if there's
> discussion on it. But hey I'd be happy if it was just always there, but
> it seems we disagree on that part.

+1 to above request.

Regarding Link tag. We've been adding them to all bpf/net commits
for quite some time and found them useful in many cases:

1. patches rarely come as a single patch. Even if it's a single line
fix there is likely a selftest in the other commit. When I investigate
a commit clicking on lore link and seeing the whole series saves a ton
of time, since search by commit name in lore.kernel.org/all/ isn't great.

2. patches rarely accepted on the first revision and we recommend developers
to add lore link to v1 when they respin v2. So by the time vN series
are accepted the cover letter has links to all previous revisions.
Similarly when I debug an issue: git blame, git show sha, click on lore link,
click on 0/N, click on v2-v3, since most of the interesting discussion
happens in earlier revisions. The last few respins will typically address
final nits.

3. even if it's a rare single commit the patch subject doesn't say
whether it was v1 or v2, while lore has this information in email
like [PATCH bpf-next v2] subj. Going to lore and realizing that
ohh it was v2 that was accepted is a lot better than search by subject
and seeing v1, v2, v3 versions of the same patch and not being able
to tell which one was applied.

So the only case where Link is useless is the case of single commit
without any revisions that was accepted on the first try.
We can manually remove such links, but this would be tedious
manual work, since automation is tailored for common case where
link is in every commit and they are useful.