https://www.kernel.org/doc/html/v6.6/process/stable-kernel-rules.html#

关于Linux稳定版本的一切你想知道的内容

关于哪些补丁被接受，哪些不被接受进入“-stable”树的规则：

它或等效的修复必须已经存在于Linus的树（上游）中。
它必须明显正确且经过测试。
它的大小不能超过100行，包括上下文。
它必须遵循Documentation/process/submitting-patches.rst中的规则。
它要么修复了一个真正困扰人们的错误，要么只是添加了一个设备ID。对于前者的详细说明：
- 它修复了像oops、hang、数据损坏、真正的安全问题、硬件怪癖、构建错误（但不适用于标记为CONFIG_BROKEN的内容）或一些“哦，那不好”的问题。
- 如果用户报告的发行版内核存在严重问题，而这些问题修复后可以解决显著的性能或交互性问题，也可以考虑接受。由于这些修复不太明显且存在较高的潜在回归风险，它们只能由发行版内核维护者提交，并包含一个链接到bugzilla条目（如果存在）以及有关用户可见影响的其他信息。
- 不接受“这可能是个问题…”这种类型的事情，比如“理论上的竞争条件”，除非还提供了有关如何利用该错误的解释。
- 不接受对用户没有好处的“琐碎”修复（拼写更改、空白清理等）。

向“-stable”树提交补丁的流程

注意
安全补丁不应（仅）通过“-stable”审查流程处理，而应遵循Documentation/process/security-bugs.rst中的程序。

有三种选项可以向“-stable”树提交更改：

在您提交给主线的补丁的描述中添加一个“stable tag”。
请求稳定团队接收已经合并到主线的补丁。
提交一个与已经合并到主线的更改等效的补丁给稳定团队。

下面的部分详细描述了每个选项。

选项1是首选，它是最简单和最常见的。选项2主要用于在提交时未考虑回溯的更改。选项3是两个早期选项的替代方案，适用于主线补丁需要调整以适应旧系列（例如由于API更改）的情况。

在使用选项2或3时，您可以要求将您的更改包含在特定的稳定系列中。在这样做时，请确保修复或等效修复适用、已提交或已存在于所有仍受支持的较新稳定树中。这旨在防止用户在更新时可能遇到的回归问题，例如，如果为5.19-rc1合并的修复将被回溯到5.10.y，但不会回溯到5.15.y。

选项1

要使您提交的补丁在稍后自动应用于稳定树，请在签名区域中添加标签

Cc: stable@vger.kernel.org

。一旦补丁合并到主线，它将被应用到稳定树中，作者或子系统维护者无需执行其他操作。

要向稳定团队发送附加说明，请使用shell风格的内联注释：

要为挑选樱桃补丁指定任何附加的补丁先决条件，请在签名区域中使用以下格式：

    Cc: <stable@vger.kernel.org> # 3.3.x: a1f84a3: sched: Check for idle
    Cc: <stable@vger.kernel.org> # 3.3.x: 1b9508f: sched: Rate-limit newidle
    Cc: <stable@vger.kernel.org> # 3.3.x: fd21073: sched: Fix affinity logic
    Cc: <stable@vger.kernel.org> # 3.3.x
    Signed-off-by: Ingo Molnar <mingo@elte.hu>

标签序列的含义是：

    git cherry-pick a1f84a3
    git cherry-pick 1b9508f
    git cherry-pick fd21073
    git cherry-pick <this commit>

对于可能具有内核版本先决条件的补丁，请在签名区域中使用以下格式：

Cc: <stable@vger.kernel.org> # 3.3.x

标签的含义是：

git cherry-pick <this commit>

对于从指定版本开始的每个“-stable”树。

注意，如果稳定团队可以从Fixes:标签中推导出适当的版本，则不需要此类标记。
要延迟挑选补丁，请使用以下格式：

Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
对于任何其他请求，只需在稳定标签中添加一个注释。例如，这可以用于指出已知问题：

Cc: <stable@vger.kernel.org> # see patch description, needs adjustments for <= 6.3

选项2

如果补丁已经合并到主线，请发送一封电子邮件至stable@vger.kernel.org，其中包含补丁的主题、提交ID、您认为应该应用该补丁的原因以及您希望应用该补丁的内核版本。

选项3

在验证补丁是否符合上述规则后，将补丁发送到stable@vger.kernel.org，并提及您希望应用该补丁的内核版本。在这样做时，您必须在提交的更改日志中使用单独的行在提交文本上方清楚地记录和证明与原始上游补丁的偏差，例如：

commit <sha1> upstream.

或者：

[ Upstream commit <sha1> ]

如果提交的补丁与原始上游补丁有所偏差（例如，因为它必须针对旧的API进行调整），则必须在补丁描述中清楚地记录和证明这一点。

提交后

发送者将在补丁被接受到队列中时收到一个ACK，如果补丁被拒绝，则收到一个NAK。这个响应可能需要几天时间，具体取决于稳定团队成员的安排。

如果被接受，补丁将被添加到“-stable”队列中，由其他开发人员和相关子系统维护者进行审查。

"Review cycle"（审查周期）

当稳定维护者决定进行审查周期时，补丁将被发送至审查委员会，并抄送给受影响区域的维护者（除非提交者就是该区域的维护者），同时抄送至linux-kernel邮件列表。
审查委员会有48小时的时间来确认（ACK）或否决（NAK）该补丁。
如果该补丁被委员会成员拒绝，或者linux-kernel成员对该补丁提出异议，提出了维护者和成员未意识到的问题，该补丁将从队列中删除。
确认（ACK）的补丁将作为发布候选版本（-rc）再次发布，供开发人员和测试人员测试。
通常只发布一个-rc版本，但如果存在任何未解决的问题，可能会修改或删除一些补丁，或者排队一些额外的补丁。然后发布并测试额外的-rc版本，直到没有发现问题为止。
对-rc版本的回应可以通过邮件列表发送“Tested-by:”邮件，附上所需的任何测试信息。将收集“Tested-by:”标签，并添加到发布提交中。
在审查周期结束时，将发布包含所有排队和经过测试的补丁的新的稳定版本。
安全补丁将直接从安全内核团队接受到稳定树中，并不经过正常的审查周期。有关此流程的更多详细信息，请联系内核安全团队。