Re: [RFC] docs: netdev: additional info requirements for bug fixes

[Sabrina Dubroca <sd@queasysnail.net>]

2026-07-28, 16:08:20 -0700, Jakub Kicinski wrote:
> On Wed, 29 Jul 2026 00:56:31 +0200 Sabrina Dubroca wrote:
> > If that's the case, good. But "quote this text at people until they
> > comply" and "get an AI bot looking at all patches coming in" doesn't
> > sound like that to me.
> 
> IMO it's really very useful for reviewers to know if the author
> triggered the issue.

People usually add that information if they did. If it's not present,
we should assume they didn't, and treat it as belonging to the "AI
report/other-tool report/code analysis" bucket?

> Also, for downstream backporters it's useful 
> to know in case of conflict whether to invest time in resolving
> or the patch is mostly theoretical and waiting until next major is fine.

For downstream backports, there can be a number of differences that
make an issue either easier or harder/impossible to trigger. But sure,
that's a useful baseline.


If we could reword the statement to include something like (with a
formulation/presentation similar to your patch, this is a short/ugly
version):

Fixes should describe if and how the issue was triggered/reproduced.
This information should describe how likely it is to happen in real
life [stuff about delays/fault injection/etc]. If this information is
missing, we WILL assume the bug was found through code analysis
(whether by human or tool/AI) and not actually triggered on a live
system.
[something about such patches being penalized in the reviews/queue?
I don't know]


my concern about having to add a bunch of uninformative text would go
away.

> I'm also guilty of not adding "impact to the user" info, but that
> requires thinking and theorizing. The ask here is to purely state
> the facts.

So just something like "possible UAF/memleak/deadlock/some unwanted
behavior" is what you expect here? That's totally reasonable. I
thought you meant something more abstract.

> FWIW the immediate trigger for me is the people who started sending
> sloppy fixes to drivers that nobody uses. I ask them about the
> discovery process and half of the time they don't even respond.

Sure, I get that, you're drowning in pointless slop.

An alternative could be an AI bot that looks at "fixes" and checks if
they're likely to ever happen (or have a measurable impact. a tiny
memleak when a device is initialized/module is loaded, even with great
reproduction steps in the commit message, still falls in the "don't
care" category IMO). My experiments with "find a way to trigger this
code path" have been pretty good, so I guess if the bot comes up with
"basically can't happen", that would be fairly reliable.

-- 
Sabrina