Re: [PATCH v3 3/7] docs: stable-kernel-rules: drop rules the stable trees do not apply

[Bradley Morgan <brads@mainlining.org>]

On 16 October 2026 16:28:23 BST, Sasha Levin <sashal@kernel.org> wrote:
>The stable trees do not apply the 100 line limit or the exclusion of
>theoretical issues, and they require a fix to be correct and tested
>rather than obviously correct. Drop those rules.
>
>Assisted-by: LLM
>Signed-off-by: Sasha Levin <sashal@kernel.org>
>---
> Documentation/process/stable-kernel-rules.rst | 6 +-----
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
>diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst
>index edf90bbe30f43..625c1b5b0e16b 100644
>--- a/Documentation/process/stable-kernel-rules.rst
>+++ b/Documentation/process/stable-kernel-rules.rst
>@@ -7,8 +7,7 @@ Rules on what kind of patches are accepted, and which ones are not, into the
> "-stable" tree:
> 
> - It or an equivalent fix must already exist in Linux mainline (upstream).
>-- It must be obviously correct and tested.
>-- It cannot be bigger than 100 lines, with context.
>+- It must be correct and tested.

s/tested/fully tested ?

'Tested" to agents would be just a basic compile test, maybe we could
define here what you want the agent to do?

E.g: a W1? A QEMU repro? And others.

> - It must follow the
>   :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
>   rules.
>@@ -24,9 +23,6 @@ Rules on what kind of patches are accepted, and which ones are not, into the
>     regression they should only be submitted by a distribution kernel
>     maintainer and include an addendum linking to a bugzilla entry if it
>     exists and additional information on the user-visible impact.
>-  - No "This could be a problem..." type of things like a "theoretical race
>-    condition", unless an explanation of how the bug can be exploited is also
>-    provided.

To help agents filter bugs see below:

>   - No "trivial" fixes without benefit for users (spelling changes, whitespace
>     cleanups, etc).

What I tend to do when I use AI on my own projects to find bugs are to get
it to "verify" what it finds to be a good enough bug. Could you refer to
the security document here? That could help very well for AI agents to
find proper bugs.


Id also suggest that perhaps you *could* make a new patch saying that 

"When finding bugs, you need to verify that this bug is severe enough to
need stable backporting or a CVE, if you reckon it is not severe enough
for them, if it's not reproducible, eliminate the bug from the results"

What do you reckon Sasha?

> 
>

--- Thanks!
"I'm not a very positive person" - Linus torvalds