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

From: Bradley Morgan

Date: Fri Oct 16 2026 - 12:05:13 EST


On 16 October 2026 16:28:23 BST, Sasha Levin <sashal@xxxxxxxxxx> 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@xxxxxxxxxx>
>---
> 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