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

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 30 Jul 2026 16:12:35 +0200 Sabrina Dubroca wrote:
> 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?

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.

> > 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 :)

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

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