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

[Sabrina Dubroca <sd@queasysnail.net>]

2026-07-30, 13:50:27 -0700, Jakub Kicinski wrote:
> 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.

I'm just trying to find some space for bad memory (I still can't
remember to add "CC: stable" to my patches much of the time) and not
bloating the commit messages.

[on the "talking about tool" thing] If the information you want is
missing, handle the patch /as if/ it was the lowest class in each area
(because it probably is). That happens to be (I think) "no repro, not
tested (or just selftests, does that deserve a mention?), found by
some tool or human code review". That's why I mentioned "tool".

And I think they kind of mesh together. If it's been discovered with a
crash in production, it's "more reproduced" than just code analysis,
but actual reproduction for testing purposes may be impossible without
hacks. syzbot has probably generated repros for issues that will
rarely be hit live.

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

No, sorry, this was meant to be a reference to what you wrote:

    The reproduction should state whether kernel modifications were
    necessary (e.g. inserting a delay to widen the race). The commit
    message must disclose if error injection or loading a special
    kernel module was used to trigger the issue.

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

Then they can add the information. Their LLM will probably generate
the things you want if the doc says "patches without the info will be
penalized". (or they'll start claiming it's been hit in production? I
don't know if those things are good at lying. but the humans might, so
I could see the drawback to this idea... or the LLMs will burn a
zillion tokens to generate a reproducer?)

I don't think "Found while reading some code. Nope, I haven't bothered
using fault injection to try to trigger this." is valuable at all
(other than maybe saying "I found that without AI!"), and I'd prefer
not having to add this/not having to read this in git history.

(I've probably spent more time arguing about this than I'll ever spend
adding this stuff to my patches :) Well, not if you count the times
I'll have to send "ugh sorry I forgot again" :))


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

Agree. I just misinterpreted what you meant by "impact".

-- 
Sabrina