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

[netdev-bot+sashiko@kernel.org]

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