[PATCH net-next v2] docs: netdev: additional info requirements for bug fixes

[PATCH net-next v2] docs: netdev: additional info requirements for bug fixes

[Jakub Kicinski]

Knowing how AI-generated patches were tested would be a great help
when reviewing them. Explicitly ask people to describe the discovery
and validation process they followed.

I posted this as an RFC a while back and there were some concerns
from developers that it would gum up the process. With Linus's
recent complaints about the size of our PRs, we really need
this information. I launched an AI bot which complains if
people don't explain how bugs were discovered and tested
(look for netdev-bot+sinfo@kernel.org, s=series info).
We need to document this requirement.

Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
---
v2:
 - pure rewording, no real change
v1: https://lore.kernel.org/20260928184904.2496960-1-kuba@kernel.org
rfc: https://lore.kernel.org/20260727204724.2787038-1-kuba@kernel.org
---
CC: corbet@lwn.net
CC: skhan@linuxfoundation.org
CC: rdunlap@infradead.org
CC: workflows@vger.kernel.org
CC: linux-doc@vger.kernel.org
---
 Documentation/process/maintainer-netdev.rst | 32 +++++++++++++++++++++
 1 file changed, 32 insertions(+)

diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
index 1739d9f856c3..df220a965438 100644
--- a/Documentation/process/maintainer-netdev.rst
+++ b/Documentation/process/maintainer-netdev.rst
@@ -283,6 +283,38 @@ as a patch to the list with a commit message explaining the technical
 problems with the reverted commit. Reverts should be used as a last resort,
 when original change is completely wrong; incremental fixes are preferred.
 
+Bug fixes
+~~~~~~~~~
+
+All bug fixes must state how the issue was discovered and validated,
+and how the fix was tested. This should be done in plain English, not with
+special tags or annotations. That said, the information does not have to be
+provided if the existing trailers imply it (e.g. ``Reported-by: syzbot...``
+implies the discovery method and validation).
+
+Example statements describing discovery:
+
+ - discovered by a non-AI static analysis tool
+ - discovered by an AI code review agent
+ - discovered by manual code inspection
+ - triggered during code development
+ - triggered in CI testing
+ - observed on a machine in real use
+
+If the discovery method does not imply the issue was triggered, the commit
+message should describe the validation, i.e. how the bug was confirmed
+to be real. The commit message must disclose whether reproducing the issue
+required modifying the kernel (e.g. inserting a delay to widen a race, or
+writing a loadable module to issue the right sequence of calls) or using error
+injection. The reproduction steps should be included in the commit message
+if they are short (roughly 10 lines or fewer); longer reproducers can be posted
+online with a link included.
+
+The testing statement should explain whether the fix was tested against the
+reproducer and against kernel selftests. If the bug is in a hardware driver,
+the testing statement must include information about the HW on which the
+fix was tested.
+
 Stable tree
 ~~~~~~~~~~~
 
-- 
2.55.0

Re: [PATCH net-next v2] docs: netdev: additional info requirements for bug fixes

[Daniel Machon]

> Knowing how AI-generated patches were tested would be a great help
> when reviewing them. Explicitly ask people to describe the discovery
> and validation process they followed.
> 
> I posted this as an RFC a while back and there were some concerns
> from developers that it would gum up the process. With Linus's
> recent complaints about the size of our PRs, we really need
> this information. I launched an AI bot which complains if
> people don't explain how bugs were discovered and tested
> (look for netdev-bot+sinfo@kernel.org, s=series info).
> We need to document this requirement.
> 

Acked-by: Daniel Machon <daniel.machon@microchip.com>

Re: [PATCH net-next v2] docs: netdev: additional info requirements for bug fixes

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider.

Critical: 0 · High: 0 · Medium: 1 · Low: 0

If you believe none of the issues are legitimate, please reply to each
issue of Medium severity or higher and explain why the AI is wrong.
If any of them are legitimate and you plan to respin, please let patchwork
know by including "pw-bot: cr" as a separate line at the end of your reply
(one such reply per series is enough).

- [Medium] The new 'Bug fixes' section in
  Documentation/process/maintainer-netdev.rst applies to "All bug fixes"…

--

docs: netdev: additional info requirements for bug fixes

This commit adds a "Bug fixes" section to maintainer-netdev.rst. The
section requires fixes to state how the bug was discovered and validated,
and how the fix was tested. It also asks for short reproducers to go in the
commit message, with longer ones linked online.

> diff --git a/Documentation/process/maintainer-netdev.rst b/Documentation/process/maintainer-netdev.rst
> index 1739d9f856c3b..df220a9654387 100644
> --- a/Documentation/process/maintainer-netdev.rst
> +++ b/Documentation/process/maintainer-netdev.rst
> @@ -283,6 +283,38 @@ as a patch to the list with a commit message explaining the technical
>  problems with the reverted commit. Reverts should be used as a last resort,
>  when original change is completely wrong; incremental fixes are preferred.
>  
> +Bug fixes
> +~~~~~~~~~
> +
> +All bug fixes must state how the issue was discovered and validated,
> +and how the fix was tested. This should be done in plain English, not with

[ ... ]

> +If the discovery method does not imply the issue was triggered, the commit
> +message should describe the validation, i.e. how the bug was confirmed
> +to be real. The commit message must disclose whether reproducing the issue
> +required modifying the kernel (e.g. inserting a delay to widen a race, or
> +writing a loadable module to issue the right sequence of calls) or using error
> +injection. The reproduction steps should be included in the commit message
> +if they are short (roughly 10 lines or fewer); longer reproducers can be posted
> +online with a link included.

[Severity: Medium]
Could this conflict with Documentation/process/security-bugs.rst for fixes
to bugs that were found with AI tools?

The new section covers all bug fixes. It asks for short reproducers in the
commit message and a public link for longer ones.

security-bugs.rst says bugs found with AI assistance must be treated as
public, and then says:

  case, do not publicly share a reproducer, as this could cause unintended harm;
  just mention that one is available and maintainers might ask for it privately
  if they need it.

It says the same thing again in the AI tools section:

  Note that since the
  report will be posted to a public list, the reproducer should only be
  shared upon maintainers' request.

The Security fixes section later in maintainer-netdev.rst tells people to
use the mailing lists and not contact the netdev maintainers directly. A fix
for an AI-found security bug in networking code would therefore be posted
publicly, and the reproducer would stay in git history.

For that case, the new text says to publish the reproducer and
security-bugs.rst says not to. The commit message says AI-generated patches
are the main target, and security-bugs.rst is written for the same group.

Would it help to add an exception for security-relevant fixes here, or a
pointer to security-bugs.rst, so the two documents agree?

> +
> +The testing statement should explain whether the fix was tested against the
> +reproducer and against kernel selftests. If the bug is in a hardware driver,

[ ... ]

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260930163109.3910509-1-kuba%40kernel.org

Re: [PATCH net-next v2] docs: netdev: additional info requirements for bug fixes

[patchwork-bot+netdevbpf]

Hello:

This patch was applied to netdev/net-next.git (main)
by Jakub Kicinski <kuba@kernel.org>:

On Wed, 30 Sep 2026 09:31:09 -0700 you wrote:
> Knowing how AI-generated patches were tested would be a great help
> when reviewing them. Explicitly ask people to describe the discovery
> and validation process they followed.
> 
> I posted this as an RFC a while back and there were some concerns
> from developers that it would gum up the process. With Linus's
> recent complaints about the size of our PRs, we really need
> this information. I launched an AI bot which complains if
> people don't explain how bugs were discovered and tested
> (look for netdev-bot+sinfo@kernel.org, s=series info).
> We need to document this requirement.
> 
> [...]

Here is the summary with links:
  - [net-next,v2] docs: netdev: additional info requirements for bug fixes
    https://git.kernel.org/netdev/net-next/c/fe8a42931853

You are awesome, thank you!
-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html