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

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

[Jakub Kicinski]

Initial wave of AI-generated fixes was mostly for core and protocols
we care about. But the number of irrelevant driver fixes is slowly
increasing. Add a section of explicit exclusions to our maintainer
profile.

Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
CC: corbet@lwn.net
CC: skhan@linuxfoundation.org
CC: workflows@vger.kernel.org
CC: linux-doc@vger.kernel.org
---
 Documentation/process/maintainer-netdev.rst | 28 +++++++++++++++++++++
 1 file changed, 28 insertions(+)

diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index ec7b9aa2877f..cc4b5fa3b5c1 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -272,6 +272,34 @@ the case today. Please follow the standard stable rules in
 :ref:`Documentation/process/stable-kernel-rules.rst <stable_kernel_rules>`,
 and make sure you include appropriate Fixes tags!
 
+Bug fixes
+~~~~~~~~~
+
+Unless explicitly excluded all bug fixes should be targeting the ``net``
+tree and contain an appropriate Fixes tag.
+
+Obvious exclusions:
+
+ - fixes for bugs which only exist in ``net-next`` should target ``net-next``
+   (please still include the Fixes tag in the commit message)
+ - bugs which cannot be reached, e.g. in code paths not executed given
+   current in-tree callers
+ - fixes for compiler warnings and typos
+
+Fixes for selftests and selftest-related infrastructure (most notably
+including the ``netdevsim`` driver) are only considered ``net``-worthy
+if they substantially reduce the flakiness of the test.
+
+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;
+ - bug was discovered by a static analysis / AI tool;
+ - bug was triggered/observed only with kernel changes or fault injection.
+Fixes for such bugs should default to ``net-next`` and should **not** contain
+a Fixes tag. Networking or driver maintainers may redirect such fixes to ``net``
+at their discretion if they consider the condition to be relevant enough.
+
 Security fixes
 ~~~~~~~~~~~~~~
 
-- 
2.54.0

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

[Andrew Lunn]

> +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;
> + - bug was discovered by a static analysis / AI tool;
> + - bug was triggered/observed only with kernel changes or fault injection.
> +Fixes for such bugs should default to ``net-next`` and should **not** contain
> +a Fixes tag. Networking or driver maintainers may redirect such fixes to ``net``
> +at their discretion if they consider the condition to be relevant enough.

I would also stress what the stable rules say:

	It must either fix a real bug that bothers people or ...

Many of the bug fixes we are currently getting don't meet this
criteria, so are net-next material.

   Andrew

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

[Jakub Kicinski]

On Wed, 3 Jun 2026 21:25:02 +0200 Andrew Lunn 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;
> > + - bug was discovered by a static analysis / AI tool;
> > + - bug was triggered/observed only with kernel changes or fault injection.
> > +Fixes for such bugs should default to ``net-next`` and should **not** contain
> > +a Fixes tag. Networking or driver maintainers may redirect such fixes to ``net``
> > +at their discretion if they consider the condition to be relevant enough.  
> 
> I would also stress what the stable rules say:
> 
> 	It must either fix a real bug that bothers people or ...
> 
> Many of the bug fixes we are currently getting don't meet this
> criteria, so are net-next material.

I decided to leave that out in the end because it's a bit too open
to interpretation for my mind.

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

[Johannes Berg]

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/20260531145435.701703-1-runyu.xiao@seu.edu.cn/

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

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

[Jacob Keller]

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/20260531145435.701703-1-runyu.xiao@seu.edu.cn/
> 
> 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
>