LWN: stable kernel 争论的核心问题！
共 4536字，需浏览 10分钟
·
2021-08-13 19:04
关注了就能看到更多这么棒的文章哦～
The core of the -stable debate
By Jonathan Corbet
July 22, 2021
DeepL assisted translation
https://lwn.net/Articles/863505/
关于哪些补丁应该进入 stable update，一直有争议存在，争议还不少。因此，当最近这个话题最近再次出现时，我们基本上认为不会有什么新的信息出来。而且，基本上这次的讨论整体来说也是这样进行的，但是从这次交流中我们也能够看到推动这些讨论的核心问题究竟是什么。归根结底，对于 stable tree 应该是什么样的，有两种根本不同的看法。
5.13.2 的 stable update 并不算是小更新了，甚至已经包含了 800 个补丁。这相当于 5.13 mainline 开发周期总的 patch 规模的 5%。如果算上其他版本的 stable kernel 在同一天需要进行 review 的 patch 数量，总共有超过 2000 个 stable 版本相关的 patch 需要进行 review。哪怕对于 Linux kernel 这么大的大的社区来说，要想在原定的两天时限内处理完这些 review 也是很难做到的。即便如此，Hugh Dickins 还是对其中加入的几个内存管理 patch 提出了反对，因为这些 patch 并没有专门标明要加入到 stable release 中。他认为这些 pat 不适合 stable kernel，不应该被放进去。
stable-kernel 的维护者 Greg Kroah-Hartman 回应说，stable update 这次规模这么大，主要是由于维护者手里一直存着这些 fix 等待合并窗口放开。所以等到 -rc1 版本一发布，这些 fix 就会全部落入 stable update 中，因此，stable update 的内容就非常多了。但很明显，随着时间的推移，进入 stable kernel 的改动数量一直在不断增加。如果我们看一下每个版本的前五次 stable update 中的改动数量（应该足够能涵盖 merge-window 相关的 fixle ），结果是这样的：
| Release | Updates | Changes | |
|---|---|---|---|
| First 5 | Total | ||
| 4.19 | 198 | 754 | 19,682 |
| 5.0 | 21 | 408 | 2,387 |
| 5.1 | 18 | 353 | 1,747 |
| 5.2 | 21 | 779 | 2,429 |
| 5.3 | 18 | 561 | 2,178 |
| 5.4 | 134 | 435 | 14,414 |
| 5.5 | 19 | 653 | 2,516 |
| 5.6 | 19 | 364 | 1,864 |
| 5.7 | 19 | 581 | 2,984 |
| 5.8 | 18 | 899 | 2,755 |
| 5.9 | 16 | 1,244 | 2,339 |
| 5.10 | 52 | 841 | 7,295 |
| 5.11 | 22 | 948 | 3,588 |
| 5.12 | 19 | 1,446 | 3,843 |
| 5.13 | 4 | 1,416 | 1,416 |
开发者和维护者可以加上 "CC: stable@vger.kernel.org" 的 tag 来表明一个 mainline patch 应该被移植到 stable kernel 上去，但大多数 patch 并不是经过这个流程来进入 stable kernel 的。在 5.13.4 的 1416 个 commit 中只有 259 个（18%）包含这样的 tag。而 stable kernel 的维护者实际上在采用越来越积极地策略来主动寻找那些看起来像 fix 的 mainline patch，并把它们加到 stable kernel 中去。他们会根据在许多 patch 中都带有的 fixes 这个 tag 用来判断这个 patch 是一个需要移植的 fix patch ，此外也在使用一些机器学习的方法来选择 patch。最终的效果就是很多 commit 在没有明确 tag 的情况下就被包含进了 stable update。虽然截至目前，5.13 还没有达到发布五个稳定版本的阶段，但基本上可以预测出，它的前五个 stable-update 中会进行的改动应该会比前几个 Release 的相应数量都要多。总体来说，进入 stable update 的 patch 数量正在增加，其增速似乎超过了内核开发周期中合入的改动的增速。现在可以看到那些，long-term stable （长期稳定版）内核在其 "stable"期间收到的 patch 数量比在其的 "final" release 前的开发周期中收到的 patch 都要多。换句话说，当 Linus Torvalds 打好 tag 离开的时候，这个开发周期其实还远远没有完成。
这项工作一直有些争议，特别是当出现 regression （质量回退）的时候。实际上 regression 是不可避免的，但如果在三个月的短暂稳定周期内就给内核添加了超过 3000 个改动的话，很难想象说其中没有会导致出现问题的。这次被 Dickins 挑出来的 patch 并没有造成任何 regression（目前还没有看到相关的质量问题），但是内存管理的开发者们显然很担心这种可能性。
为了避免这样的结果，内存管理维护者 Andrew Morton 要求在没有特别要求的情况下，不要将带有他的 Signed-off-by tag 的 patch 纳入 stable update。"目前，这种 -stable 相关的乱象正在凌驾于 MM 开发者（有时是深思熟虑）的决定之上，这有点可怕"。Kroah-Hartman 问那么应该如何决定将一个 patch 标记为应该移植回 stable 呢？具体来说，为什么有一些些明确是 fix 的 patch 没有加上这些标记呢？Morton 这样解释他们的想法：
广义上讲：主要考虑对最终用户的影响。如果我们没有看到由于该问题而导致用户可见的问题的报告，并且我们预期不会出现这样的事情，那么就不要 backport 移植回去。当我们不能确定有什么好处时，为什么要冒着造成 regression 的风险？
Kroah-Hartman 的立场是，如果一个 patch 修复了某个 bug，那么它就应该包含在 stable update 中：
但是，你们都愿意花时间来在 changelog 中加上类似 "嘿，这修复了这个特定的 commit 中的 bug！" 这样的 tag，但却不愿意去 fix 带有这个 commit 的 kernel，这真的让人感觉很奇怪。这对于那些关注 changelog 的人来说是一个奇怪的行为。
Sasha Levin（他也负责稳定版的更新）补充说，如果只有明确标记过的 patch 会被 backport 回到 stable kernel 中的话，那么很多重要的 fix 就会遗漏掉。其中一些 fix 会通过其他途径来进入发行版提供商的 kernel 中去，这似乎并不是我们的理想目标。
归根结底，这就是分歧的根源：对于开发出真正 stable 和没有问题的 stable update 的最佳方式，一直存在两种不同的意见。
许多开发者认为 stable kernel 是人们精心选择出来的一些 fix 的集合，其中每一个 fix 都经过了深入的 review 从而确定这是一个重要的 fix，并且不会导致 regression。升级到这些内核应该都是完全安全可靠的，因为他们只有极小的可能会引入之前版本中不会有的问题。这种立场往往是那些复杂的、很容易就出现一些微小的质量回退的 core subsystem 开发者的共同看法。
内存管理子系统就是一个典型例子。在 2020 年底同 XFS 文件系统的开发者们也有过类似的争论。内存管理经常需要对未来的情况进行预测，因此相关代码会有很多复杂的启发式判断，需要能配合各种各样的 workload 来正常工作。因此一个看似无害的改动有时候就会在几年之后才发现它给某些客户特有的工作场景带来了性能回退。内存管理开发人员认识到，如果没有这类 regression 事件，那么他们的生活才会更顺利，所以他们会不遗余力地避免对 stable kernel 进行不必要的修改。
其他人，包括 stable 维护者，认为需要把每一个理论上应该 backport 的 fix 都移植回去才能得到最好的 kernel。开发者在 fix 许多问题的时候可能并未意识到这些 bug 对用户的影响（甚至可能是 security 影响）。还有很多 fix 实际上是在很多问题被发现之前就阻止了问题的发生。
一些发行版提供商已经采取了这个立场，因此，他们对目前的状况感到满意。Justin Forbes 写道："目前的 stable
流程中修复的 bug 比起它引入的 bug 要多"。Android kernel 也越来越多地明显地跟 stable update 紧密结合起来，这是一种能够获得尽可能多的 fix 的方式。基于这方面的经验，Kroah-Hartman 说："我有数据支持这一方的论点，还有安全相关的研究结论可以说明忽视这些 stable release 会使系统由于已知风险而暴露给攻击者"。
哪种立场是 "正确的"，目前还并不完全清楚，但是哪种立场当前 "胜出" 却是毫无疑问的。在 Linux 世界里，总是由做相关工作的人来决定该如何做这个工作，而 stable 维护者选择了这种 "混杂" 的方法。很想知道是不是会有一个社区来按照上述的更加严格的策略来维护另一个 ultra-stable kernel，不确定是否有人有时间来这样做。
在边缘地区总是有一些调整余地的，可以选择对某些子系统采取特殊策略。似乎对于内存管理方面来说可能会作为特例处理。而且如果有更多的测试的话，肯定会有帮助。这些年来 stable release 的测试情况已经有了很大的改善，但仍然可以变得更好。Ted Ts'o 建议，如果有人能有时间来创建一个 "perfbot" 系统专门来寻找性能上的 regression ，那会很有用处。不过，性能方面的 regression 是特别难以测试的，它会占用大量资源，而且几乎不可能模拟出每一种类型的 workload。
无论如何，看起来这种大规模的 stable update 将继续成为未来的主要规则。希望它们仍能继续保持很少的 regression，但没有可能保证永远不会出现 regression。因此，我们可以预测得到，这种关于什么应该或者不应该进入 stable update 的争论将无限期地持续下去。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～