Re: [PATCH net-next] docs: exclude driver and netdevsim bugs

On 6/3/2026 1:12 PM, Johannes Berg wrote:
> On Wed, 2026-06-03 at 09:29 -0700, Jakub Kicinski wrote:
>>
>> +Additionally, netdev does not consider bugs to be ``net``-worthy
>> +if they fulfill **all** of the following criteria:
>> + - bug is in a hardware device driver;
>> + - bug is either a missing error handling or is part of the error handling flow;
> 
> Do you really want to be this specific?
> 

I agree, this does feel a little overly specific. Perhaps there is
better wording to clarify the intent such that it could cover your
example as well? Hmm.

> Take this fix for example that I mentioned the other day:
> https://patchwork.kernel.org/project/linux-wireless/patch/[email protected]/
> 
> It doesn't formally fall under that definition, but I think it should,
> it's a silly thing to send to stable etc.
> 
> This isn't even a USB device where you could reasonably argue that
> someone might plug in a random one and it could be programmed to look
> like the device in question and misbehave. Sure, you can build PCIe
> hardware too that can do that, technically, and there's technically
> external PCIe via Thunderbolt, but it's still far harder to actually do
> anything with.
> 
>> + - bug was discovered by a static analysis / AI tool;
> 
> I'm not (yet?) convinced that this bullet point is right.
> 
> It risks getting into an argument about how much the LLM did to discover
> it, or if the actual discovery was a manual process after the LLM
> pointed out issues, or whatever ...
> 
> Maybe more importantly, why should that even change the result?
> 
> It's true that today the reason to start spelling this out more clearly
> is AI related, but that's really because of (a) the scale, and (b) many
> of the people running the LLMs not being aware of (and frankly often not
> really caring about) the community norms. I'm not convinced that the
> "silliness" of a change should be measured by how it originated.
> 
Right. The point to me seems that "fixes" made purely to resolve tool
hits (static analysis, checkpatch, LLM, whatever) have lower value than
fixes which have a stronger motivation such as user reports.

I'm not sure I have a better wording, and perhaps you could remove this
bit entirely.

>> + - bug was triggered/observed only with kernel changes or fault injection.
> 
> Given this fourth bullet point, we'd still accept fixes for such driver
> problems that people actually run into, while excluding "theoretical"
> things that are discovered by "reading the code".
> 

Right. One could argue that some race conditions are difficult to
trigger because a window is very narrow, and fault injection could make
it much easier... But we could still accept such fixes as development
improvement rather than through the "net" tree, so I think this criteria
is good.

> johannes
>