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

On Thu, 30 Jul 2026 16:12:35 +0200 Sabrina Dubroca wrote:

2026-07-28, 16:08:20 -0700, Jakub Kicinski wrote:

quoted

On Wed, 29 Jul 2026 00:56:31 +0200 Sabrina Dubroca wrote:  

quoted

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?

The ask is for info about discovery, repro, test.
The sentence you quoted is about repro, you seem to be talking
about tool.

I think all 3 pieces of info (discovery, repro, test env) are valuable.

quoted

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].

Here we'd ask the author to judge likelihood. Which is hard and takes
effort. My goal was to ask for pure information, no thinking effort.

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 feel bad enough accusing people of using LLMs (even when they
_obviously_ do). I don't want to accuse people of not testing their
fixes based on information missing :( I'd rather first ask them
to add such info explicitly and then shout at them :)

quoted

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.

Right, my patch doesn't ask for impact specifically.
But the direction is right - ask for info the author already has rather
than require the author to theorize about likelihood and impact, or
do extra experiments.

quoted

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.

Yes, definitely planning to do that too (once I figure out how 
to squeeze some free tokens out of the current pipeline :/)

Still, I'd also like to ask the author.