Re: [PATCH v5 3/6] agents: add a skill to determine stable tags

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 11 Nov 2026 17:59:35 -0500 "Theodore Ts'o" <tytso@mit.edu> wrote:

> From: Sasha Levin <sashal@kernel.org>
> 
> Whether a fix needs a stable tag, and which releases it should reach, is
> decided by hand and is often missed or left too broad. Add a skill that
> sends the agent to stable-kernel-rules.rst for the decision and the tag
> format, lists the kinds of changes the stable trees take and leave out
> in practice, and adds the checks agents tend to get wrong: finding the
> first release that contains each introducing commit, checking that the
> fix applies to the oldest affected release, giving every stable tag the
> same version, and following the subsystem's stable policy.
> 
> If the decision cannot be made, the skill returns no tag. Point the
> bug-fix procedure in coding-assistants.rst at the skill.
> 
> Signed-off-by: Sasha Levin <sashal@kernel.org>
> Reviewed-by: Bradley Morgan <brads@mainlining.org>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Link: https://patch.msgid.link/20261020161642.3713052-4-sashal@kernel.org
> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
> ---
>  Documentation/process/coding-assistants.rst |  6 +-
>  agents/skills/stable-tag/SKILL.md           | 72 +++++++++++++++++++++
>  2 files changed, 76 insertions(+), 2 deletions(-)
>  create mode 100644 agents/skills/stable-tag/SKILL.md
> 
> diff --git a/Documentation/process/coding-assistants.rst b/Documentation/process/coding-assistants.rst
> index ca1cc255606b..81ee530a8a7f 100644
> --- a/Documentation/process/coding-assistants.rst
> +++ b/Documentation/process/coding-assistants.rst
> @@ -37,6 +37,8 @@ The following skills are available:
>  
>  * agents/skills/find-fixes/SKILL.md determines the Fixes tag of a bug fix, or
>    checks an existing one.
> +* agents/skills/stable-tag/SKILL.md decides whether a fix goes to stable and
> +  returns its stable tag, or checks an existing one.
>  
>  Licensing and Legal Requirements
>  ================================
> @@ -83,8 +85,8 @@ these steps:
>     another one. The fix must not add build warnings and must pass the
>     checkpatch.pl checks (see submitting-patches.rst).
>  6. Commit the working fix with a detailed message describing the problem, the
> -   solution and a Fixes tag determined with the find-fixes skill.  Do not
> -   add a Signed-off-by tag.
> +   solution, a Fixes tag determined with the find-fixes skill, and a stable
> +   tag if the stable-tag skill calls for one.  Do not add a Signed-off-by tag.
>  7. Identify the maintainers and lists using scripts/get_maintainer.pl.
>     Documentation/process/security-bugs.rst shows how to do that.
>  8. Indicate what could not be done. If the fix could not be built or tested, or
> diff --git a/agents/skills/stable-tag/SKILL.md b/agents/skills/stable-tag/SKILL.md
> new file mode 100644
> index 000000000000..d87bcc95089d
> --- /dev/null
> +++ b/agents/skills/stable-tag/SKILL.md
> @@ -0,0 +1,72 @@
> +---
> +# SPDX-License-Identifier: GPL-2.0-only
> +name: stable-tag
> +description: >-
> +  Decide whether a Linux kernel fix should be backported to stable kernels
> +  and return verified Cc: stable tag lines. Use when preparing or reviewing
> +  bug-fix patches, drafting their commit messages, or checking an existing
> +  stable tag.
> +---
> +
> +# Determine a stable tag
> +
> +Read Documentation/process/stable-kernel-rules.rst. It says which changes go
> +to stable and how to write the tag, its prerequisites and its version. Follow
> +the rules for skills in Documentation/process/coding-assistants.rst.
> +
> +Judge a change by what it does, not by how its description labels it: a
> +"cleanup" that releases a resource on an error path fixes a leak. In practice,
> +the stable trees take:
> +
> +- Fixes for crashes, oopses, BUG and WARN splats, hangs, lockups, RCU stalls,
> +  deadlocks, data corruption and security issues.
> +- Fixes for use-after-free, double free, NULL pointer dereferences,
> +  out-of-bounds accesses, integer overflows, uninitialized data, reference
> +  counting errors, and memory or resource leaks.
> +- Fixes for races, including data races.
> +- Fixes for incorrect behavior, such as wrong results, wrong hardware
> +  programming, or endianness and type errors.
> +- Fixes for problems reported by syzbot, other fuzzers, or the KASAN, KMSAN,
> +  KCSAN and UBSAN sanitizers.

Marco had some thoughts on this just today:

https://lore.kernel.org/CANpmjNMvM_TCs7Fao9+gM-NNpQyBKYumSuWOt_03ZX+tLwbjWw@mail.gmail.com

And Documentation/process/stable-kernel-rules.rst does ask for real
things, not theoretical stuff.

Also, I would keenly like to see changelogs clearly explain *why* a
backport is proposed.  As I have said 1000 times, "when fixing a bug
please clearly describe the userspace-visible runtime effects of that
bug".  Can we pleeeeeeeeeeze get this requirement clearly enshrined in
this patcset somewhere where the LLMs will read it and comply?  It's
really simple for the LLMs to cook up a paragraph for this, if so
directed.