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
