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 >
