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? 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. > + - 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". johannes
