本文围绕stable kernel补丁选择展开讨论。当前合并到stable update的补丁数量大幅增加，虽增加了有用修复的数量，但也提高了引入错误修复的概率。以XFS文件系统的回归bug为例，探讨了stable update和mainline kernel -rc版本的关系，认为需在快速修复和避免回归间找平衡。
关注了就能看到更多这么棒的文章哦～
XFS, stable kernels, and -rc releases
By Jonathan Corbet
December 3, 2020
DeepL assisted translation
https://lwn.net/Articles/838819/
自从开始进行 stable kernel 的流程以来，人们就一直在讨论哪些 patch 适合包含在这些 stable update 中。通常来说，这些讨论的发起者都是那些认为标准应该更加严格的人。在 5.9.9 的 stable update 中发现的 XFS 文件系统中的一个回归 bug，又一次短暂地引发了关于这个话题的热烈讨论。从某种意义上说，这次质量回退 bug 没有涉及什么新的特点，但是人们提出了一个关于 stable update 和 mainline kernel -rc 版本之间关系的有趣观点。
一开始，stable update 只限于 critical fix，但随着时间的推移，这个规则被放宽了。现在，合并到 stable update 的 patch 通常是通过机器学习系统自动选择的。其他的 patch 则是因为它们看起来像是修复了某个地方的问题。这就导致了进入 stable update 的补丁数量大幅增加。5.9.x 系列发展到 5.9.11 的时候已经打上了超过 1900 个 patch，而 4.9 和 4.9.246 之间的差异则远远超过 18000 个补丁。
合入所有这些 patch 无疑会增加 stable release 中真正有用的 fix 的数量，这是一件好事。但这同时也增加了合入错误的 fix 的概率，这些错误的 fix patch 为用户带来了不好的体验，用户想要的是没有问题的 release。
例如，这个 XFS "fix"(https://lwn.net/ml/linux-xfs/160494584816.772693.2490433010759557816.stgit@magnolia/) 在 11 月 9 日被发布到 linux-xfs 的邮件列表中，它经过了 review，被合入，并最终在四天之后被推送到 mainline，出现在 5.10-rc4 版本中。17 日的时候，Greg Kroah-Hartman 将这个 patch 和其他 254 个 fix 一起列入 5.9.9 review cycle。没有人提出反对意见，因此该 patch 在最初发布十天后，也就是 19 日，就成为了 5.9.9 版本的一部分。
又过了三天时间，Nick Alcock 报告说在运行当前的 stable kernel 时出现了 XFS 损坏错误。Wong 的 patch 就是这个问题的源头。事实上，XFS 的开发者已经在 5.10-rc5 的 mainline 中对这个 patch 进行了 revert 操作（Eric Sandeen 最先报告出这个问题）。这个问题在 11 月 24 日的 5.9.11 update 中得到了解决。因此，有大约五天的时间，当时的 stable 5.9 kernel 出现了一个 bug，使得 XFS 文件系统在某些配置环境下无法使用。值得注意的是，尽管 XFS 报告说出现 corruption，但并没有发生文件系统损坏事件，只是无法 mount 上来了。
这个事件就这样结束了，stable kernel 的机器学习系统为后来的 5.9.x release 挑选了另一个 XFS patch。这时，Dave Chinner 提出了反对意见：
我们在这个 -rc 周期中已经有一个 XFS upstream kernel 的质量回退问题被同步到了 5.9.9 的 stable kernel 上，就是因为我们的 stable 处理流程在被 Linus 合并后的几个小时内接收到了一堆 XFS fix。其中有一个提交是一个没有考虑周到的结果，尽管我们在几天内就发现了它并进行了 revert，但 stable kernel 的用户可能已经有几个星期都会受这个问题的影响。这*不应该发生*
Chinner 表示，stable 挑选流程太快，导致一些合并到主线的 patch 中发现问题再 fix 的时候已经被合入 stable 了，他希望在 XFS patch 出现在最终的 mainline release 中之前，不要加入 stable update 中。
维护 patch 选择自动化系统的 Sasha Levin 回答说，真正的问题在于 XFS 的质量控制流程里面，他说，一开始就不应该让错误的 patch 通过。当一个改动进入 mainline 的时候，人们就应该认为它是正确的：
stable 流程假定最终在 upstream 的 commit 都经过了 review 和 test；stable 过程并没有提供太多对具体补丁的深入 review，而是主要集中对数百个 patch 合入到每个 stable branch 之后的产品进行测试。
对于 Levin 试图将责任推给 XFS 方面的做法，Chinner 表示强烈反对。这个 bug，只会在使用新的 user space 和旧的 kernel 配合的情况下出现，而这并不是正常的 patch merge 之前测试的场景。XFS 开发者所做的后续测试最终确实发现了这个问题，此时问题已经被修复。他说，期望每个补丁在合入前都要经过这种程度的测试，这不是个合理的需求。
他说，重要的是，现实中并不是所有的问题都能在 patch 进入 mainline 之前被发现。
我在这里重复一下我们该吸取的教训：将一个提交合并到 Linus 的 tree 中并不意味着它已经完全测试过和准备实际应用了。它只是意味着它已经通过了不少单元测试而没有出现 regression，因此被认为是准备好了由更多的开发人员和测试人员进行更广泛的集成测试。
他又说，stable 流程需要需要放慢一些速度，以便进行更广泛的测试，后来在另一个讨论中重复了这个观点，引来了 Kroah-Hartman 的反对：
这意味着全世界将持续 3 个月 没有将一些已知有效的 fix 合入到代码 tree 中？这对我来说是不能接受的，因为我开始做这件事是因为它确实有必要，而不仅仅是因为我想做更多的工作……
Chinner 随后澄清说，在他看来，大多数子系统都不需要多等一段时间。他还建议，对于那些出现 regression 后影响会是灾难性的子系统（例如文件系统）来说，也许等待两个 -rc 周期就足够了。
在将 patch 合入到 stable update 之前，需要更多的时间来对它进行测试，这一点在过去已经得到了认可。最初，任何进入 mainline 的 patch 都被认为是 stable-update 进行公平考虑的结果。不过，后来这个规则被修改为要求 patch 必须先出现在至少一个-rc 版本中。但这仍然没有给 mainline 中的问题暴露留出足够的时间。
每一个开发周期都会有七八个 -rc 版本，这也就侧面说明了 -rc 版本可能是包含 bug 的。进入-rc 版本，并不代表这个 patch 就一定能出现在最终的 mainline 版本中，patch 通常会先经过几个-rc 版本的测试。但 stable update 可以在这些 patch 出现在-rc 版本中后立即打上这些 patch。因此，从某种意义上说，对于大多数安装好的系统来说，mainline 还算不上足够稳定，但比起广泛使用的 stable release 来说，mainline 的要求更加严格。
对话到此结束，没有迹象表明想法有任何改变。不过毫无疑问，这个话题还会回来。在 stable release 中引入的 bug 违背了人们当初希望使用这些版本的理由，所以这些 bug 肯定会引起人们的关注。不过，无论过程多么缓慢或多么谨慎，出现这种问题的可能性永远不会是零。我们必须在尽可能快地让用户得到尽可能多的 fix，和避免 regression 的需求之间找到一个平衡点。如果 "after one -rc release" 的规则导致产生了过多的 regression，那么也许是时候让社区更清楚地阐明当一个 patch 登陆 mainline 时意味着什么，并且相应地调整 stable update 的 patch 选择过程了。
全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。
欢迎分享、转载及基于现有协议再创作～
长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～
扫一扫
517
到【灌水乐园】发言
