Linux 内核回归Regression报告指南从不引入回归规则到 regzbot 追踪实战【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux导读本文基于 Linux 内核官方文档 Documentation/admin-guide/reporting-regressions.rst系统讲解 Linux 内核开发的第一规则——我们不制造回归We dont cause regressions对普通用户意味着什么如何准确判断一个问题是否属于回归、如何规范地提交回归报告、如何利用内核回归追踪机器人 regzbot 让报告进入官方追踪队列以及面对各种边界情况性能下降、外部内核模块损坏、安全修复引发的回归、staging 树代码等该如何判断与应对。读完本文你将掌握一套从发现异常到报告被受理并修复的完整、可操作的实战流程。什么是回归什么是不引入回归规则Linux 内核创始人兼首席开发者 Linus Torvalds 亲自确立了 We dont cause regressions我们不引入回归这条规则并持续确保它被遵守。回归的精确定义如果某个应用程序或实际使用场景在旧版 Linux 内核上运行良好但在使用相似配置编译的更新版本内核上运行变差或完全无法运行这就构成一次回归。不引入回归规则禁止这种情况发生如果它意外发生造成问题的开发者应当被要求尽快修复。例如Linux 5.13 中工作正常的 WiFi 驱动在 5.14 中完全无法工作、明显变慢或行为异常——这是回归一个原本运行正常的应用程序在新内核版本上突然出现异常行为——这也是回归这类问题可能由 procfs、sysfs 或内核向用户态软件提供的众多其他接口的变化引起。但需要注意两点前提条件配置相似本例中的 5.14 必须使用与 5.13 相似的内核配置构建。可以通过make olddefconfig实现下文详述。实际使用场景开发者即使面对不引入回归规则也有权改变内核的任何方面甚至改变对用户态的 API 或 ABI——只要不破坏任何现有应用或使用场景。换言之规则保护的是用户能感知的行为而非代码或接口本身。同时要明确规则的边界不引入回归规则只覆盖内核向用户态提供的接口不适用于内核内部接口如模块 API外部开发的驱动程序正是通过这类内部接口挂钩内核的。重要提示TL;DR三条速览文档开篇为用户提供了三条快速要点判断如果某个功能在旧内核上正常、在新内核上变差或失效即构成回归。注意新内核需以相似配置编译。报告按照 Documentation/admin-guide/reporting-issues.rst 的流程报告问题该文档已覆盖回归相关的所有要点。其中两条尤为关键报告主题以[REGRESSION]开头并抄送CC或转发至回归邮件列表regressionslists.linux.dev。可选但推荐在发送或转发报告时通过指定回归发生的时间范围让 Linux 内核回归追踪机器人 regzbot 追踪该问题#regzbot introduced: v5.13..v5.14-rc1上面示例表示Linux v5.13 仍工作正常v5.14-rc1 是首次出现问题的版本。如果已经通过 bisection二分定位找到引入回归的提交则直接指定该提交的 commit-id#regzbot introduced: 1f2e3d4c5d如何报告回归完整实操流程报告回归本质上就是按照通用问题报告指南 Documentation/admin-guide/reporting-issues.rst 来操作但回归有几个额外要点。以下是完整的报告流程1. 报告前的检索与准备检索已有报告除了常规渠道还应搜索 Linux regressions 邮件列表 的归档以及 regzbot 的 Web 界面linux-regtracking.leemhuis.info/regzbot/看是否已有相同问题的讨论可以加入。如果找到匹配报告加入讨论而非另发新报告。使用 vanilla纯净内核安装和测试时确保内核是 vanilla 版本未打补丁、未使用附加模块并确保内核在健康环境中构建和运行、问题发生前未被污染tainted。参见 Documentation/admin-guide/reporting-issues.rst 中关于准备工作与 tainted 检查的说明。独立报告多个问题如果同时遇到多个内核问题请分别报告。报告中包含所有与问题相关的信息如所用内核版本和发行版。2. 撰写报告主题与内容规范主题以[REGRESSION]开头这是高优先级问题的专门处理方式见 reporting-issues.rst 的 Special handling for high priority issues 一节。清晰说明两个关键版本最后正常工作的内核版本以及第一个出现问题的版本。理想情况下使用 bisection 找到罪魁提交culprit commit。bisection 成功后报告主题的第二部分使用引入回归的那个变更的标题报告中写明罪魁提交的 commit-id抄送该提交的作者以及提交信息中以Signed-off-by:开头的行中列出的所有人即 sign-off 链上的每个人。bisection 未成功时报告中说明最新测试正常工作的版本如 5.7和最早出现问题的版本如 5.8-rc1。3. 发送与抄送规则邮件报告抄送回归邮件列表regressionslists.linux.dev。Bug 追踪器报告如果问题需要提交到某个 Web 追踪器先提交然后转发forward报告邮件至回归邮件列表同时抄送相关子系统的维护者及其邮件列表。转发时务必内联报告正文不要作为附件并在顶部附上一小段说明注明对应工单的 URL。stable/longterm 系列内的回归例如 v5.15.3 升级到 v5.15.5 出现问题记得抄送 Linux stable 邮件列表stablevger.kernel.org。4. 报告发出后的跟进义务报告发出只是开始。文档明确要求公开、及时地回应任何询问测试开发者提出的修复补丁主动复测至少在每一个新的 mainline 候选版本RC发布时重新测试并回报结果事情停滞时友好地提醒如果无人响应或响应不理想尝试自助解决问题。5. 用 bisection 定位罪魁提交如何找到罪魁提交答案是执行bisection二分定位。大致流程见 Documentation/admin-guide/reporting-issues.rst详细步骤见 Documentation/admin-guide/bug-bisect.rst新手建议先阅读完整的 Documentation/admin-guide/verify-bugs-and-bisect-regressions.rst。核心命令序列摘自 bug-bisect.rstgit bisect start git bisect good v6.0 git bisect bad v6.1之后每个测试点都执行cp ~/prepared_kernel_.config .config make olddefconfig编译安装启动后若功能正常执行git bisect good若仍然损坏执行git bisect bad。Git 会打印类似Bisecting: 675 revisions left to test after this (roughly 10 steps)的提示直到输出... is the first bad commit找到罪魁提交。重要建议如果难以可靠复现问题考虑与其他受影响用户合作共同缩小搜索范围bisection 时只要判断错一次后续整个流程就会完全偏离方向因此在不确定时宁可多花几分钟测试确保对 Git 的判定是正确的完成后保存现场以便报告使用git bisect log ~/bisection-log cp .config ~/bisection-config-culprit git bisect reset推荐的可选验证在最新代码库上尝试git revert --no-edit culprit-commit-id回退罪魁提交若回退后问题消失即验证了 bisection 的正确性也为开发者提供了通过 revert 解决回归的路径。6. 谁负责找到根因受影响代码领域的开发者应当自行尝试定位罪魁提交。但对开发者而言很多问题只出现在其触达不到的特定环境中——例如特定的硬件平台、固件、Linux 发行版、系统配置或特定应用。因此最终往往需要报告者自己定位罪魁提交有时甚至需要报告者随后运行额外测试以精确定位根因。开发者应当提供建议并在力所能及的范围内提供合理帮助让这一过程对普通用户来说相对轻松、可达成。7. 遇到问题可以咨询谁向回归邮件列表regressionslists.linux.dev发送邮件同时抄送 Linux 内核回归追踪员regressionsleemhuis.info如果问题更适合私下处理可以省略列表。让 regzbot 追踪你的回归命令全解为什么需要回归追踪规则需要有人确保被遵守否则规则会被有意或无意地破坏。Linux 内核发展史证明了这一点。为此Linux 内核回归追踪员 Thorsten Leemhuis 与一些人共同确保所有回归在解决前都被持续关注直到其被修复。由于内核开发过程高度分散、结构松散完全手工追踪已被证明极其困难因此 regzbot 应运而生——其长期目标是为所有参与者尽可能自动化回归追踪。regzbot 的工作方式监视被追踪回归报告的回复同时它还会寻找通过Link:标签引用这些报告的已发布或已提交补丁并同样追踪这些补丁帖子的回复。综合这些数据regzbot 能够很好地反映修复过程的当前状态。为什么你应该让 regzbot 追踪你的报告在你的邮件中加入 regzbot command 符合你自己的利益因为它能确保报告不会悄无声息地石沉大海。如果你省略这一步Linux 内核的回归追踪员会在你抄送回归邮件列表后替你告知 regzbot——但追踪员只是一个人有时需要休息偶尔甚至想暂时离开电脑听起来很疯狂但确实如此。依赖这一个人会导致你的回归被列入追踪列表及 regzbot 的每周回归报告的时间被不必要地推迟。这种延迟可能导致 Linus Torvalds 在决定继续开发还是收尾发布最终版本时对重要的回归一无所知。完整的 regzbot 命令参考在报告的直接或间接回复中使用 regzbot command。最简单的方式在你的已发送文件夹或邮件列表归档中找到报告邮件用邮件客户端的全部回复Reply-all功能回复它。以下命令必须放在独立段落中即用空行将这些命令与邮件正文的其余部分分隔开命令作用#regzbot introduced: 1f2e3d4c5d更新回归开始发生的时间例如 bisection 之后也可用v5.13..v5.14-rc1形式指定版本范围#regzbot title: foo设置或更新回归的标题#regzbot monitor: URL监视讨论该问题或修复的邮件线程或 bugzilla.kernel.org 工单monitor 仅对 lore.kernel.org 与 bugzilla.kernel.org 有效#regzbot link: URL指向带有更多相关细节的位置如略有相关但主题不同的邮件列表帖子或追踪器工单#regzbot invalid: wasnt a regression, problem has always existed将回归标记为无效regzbot 还支持一些主要由开发者或回归追踪人员使用的其他命令以及上述命令的更多细节可参见 regzbot 的入门指南与参考文档。regzbot 适合追踪哪些问题regzbot 设计用于追踪回归因此请不要为普通问题启用 regzbot。但对严重问题如系统挂起、数据损坏或内部错误Panic、Oops、BUG()、warning 等使用 regzbot 追踪是被允许的。此外如果某个 CI 系统发现的回归可能影响实际使用场景并会被用户注意到也欢迎将其加入 regzbot 的追踪。如何查看 regzbot 当前追踪了哪些回归查看 regzbot 的 Web 界面linux-regtracking.leemhuis.info/regzbot/即可获得当前被追踪的回归列表。另外regzbot 通常会在每周日晚上UTC发送一次Linux regressions reportLinux 回归报告这通常比 Linus 发布新的预版本早几个小时。常见问题深度解析判断一个情况是否属于回归文档以问答形式澄清了大量边界情况以下逐一解析。真的所有回归都会被修复吗几乎全部都会被修复——前提是造成回归的变更罪魁提交被可靠地识别。有些回归无需罪魁提交也能修复但通常识别罪魁提交是必须的。升级软件就能避免的问题算回归吗几乎总是算。如果开发者告诉你这不算是回归请按前述方式向回归追踪员咨询。新内核更慢或更耗电算回归吗算但差异必须显著。例如微基准测试中 5% 的变慢不太可能被认定为回归除非它也影响某个广泛基准测试超过 1% 的结果。有疑问时请咨询。外部内核模块在升级后损坏算回归吗不算。不引入回归规则针对的是内核向用户态提供的接口与服务不涵盖外部开发的内核模块的构建或运行——这些模块运行在内核空间通过偶尔会发生变化的内部接口挂钩内核。安全修复导致的回归如何处理在极少数情况下安全问题无法在不引起回归的前提下修复此时安全修复优先因为从长远看它是较小的恶。幸运的是这种权衡几乎总能避免——受影响领域的关键开发者、往往还有 Linus 本人都会非常努力地在不引起回归的情况下修复安全问题。如果你确实遇到这种情况先检查邮件列表归档确认人们是否已尽力避免回归。如果没有就报告它有疑问时按前述方式咨询。修复一个回归必然导致另一个回归怎么办这种情况确实会发生但幸好不常发生。发生时受影响代码领域的资深开发者应研究该问题找到能避免回归或至少降低其影响的修复方案。如果你遇到此类情况按照安全修复引发回归的流程处理检查先前的讨论是否已有人尽力而为有疑问时咨询。预防之道这类两难局面本可以避免——如果人们定期对每个开发周期的 mainline 预发布版本如 v5.15-rc1 或 -rc3进行一轮测试。设想某个在 v5.14 与 v5.15-rc1 之间合入的变更引起了回归但它同时又是 5.15-rc1 某个改进的硬性前提。如果有人在 5.15 发布前发现并报告了它所有这些变更通常可以直接回退、回归就此解决。但几天或几周后这个解决方案可能就不可行了——因为某些软件可能已经开始依赖后续某个变更引入的方面此时回退所有变更会对该软件用户造成新的回归因此不可取。数月前被移除的功能算回归吗算但由于上一节所述原因此类回归往往很难修复需要逐案处理。这也是定期测试 mainline 预发布版本符合所有人利益的另一个原因。似乎只有我一个人受影响规则还适用吗适用但仅限于实际使用场景Linux 开发者希望保留移除只存在于阁楼和博物馆里的硬件支持的自由。另外请注意有时回归无法避免——而进步是防止 Linux 停滞所必需的。因此如果回归只影响极少数用户出于更大的利益可能符合他们和所有人的利益而让事情通过尤其是存在某种简单的规避方法时例如更新某些软件或使用为此专门创建的内核参数。回归规则适用于 staging 树中的代码吗不适用。根据 drivers/staging/Kconfig 中覆盖所有 staging 代码的配置选项帮助文本自早期起它就声明Please note that these drivers are under heavy development, may or may not work, and may contain userspace interfaces that most likely will be changed in the near future.不过staging 开发者们通常也会遵守不引入回归规则但有时为了取得进展会稍微变通——例如当 staging 树中的一个 WiFi 驱动被一个完全从零编写的新驱动替换时一些用户就不得不应对通常是微不足道的回归。为什么新内核必须以相似配置编译因为 Linux 内核开发者有时会合入已知会引起回归的变更但将其做成可选并在内核的默认配置中禁用它们。这一技巧既允许进步又避免不引入回归规则导致停滞。考虑一个例子某个新安全特性会封锁一些经常被恶意软件滥用的内核接口而这些接口恰恰是少数不常用应用运行所需的。上述做法让两方都满意使用这些应用的人可以关闭新安全特性而其他人可以放心启用它而不会遇到麻烦。**如何创建与旧内核相似的配置**用已知良好的内核启动机器然后对新版本执行make olddefconfig这会让内核的构建脚本以当前运行内核的配置文件.config作为将要编译的新配置的基础随后所有新配置项被设置为其默认值这应当会禁用那些可能引起回归的新特性。用预编译的 vanilla 内核发现的回归可以报告吗可以但前提是你必须确认新内核使用了与旧内核相似的配置文件见上——因为构建这些内核的人可能为新内核启用了某些已知不兼容的特性。如有疑问请向内核提供方报告此事并寻求建议。内核开发者的配套视角本文聚焦用户视角但了解开发侧的配套流程有助于理解整体机制详见 Documentation/process/handling-regressions.rst子系统维护者负责落实规则并受到树维护者的监督与支持——例如 mainline 的 Linus Torvalds以及各 stable/longterm 系列的 Greg Kroah-Hartman 等人修复回归的补丁应使用Closes:标签指向所有报告该问题的地方regzbot 对Link:标签同样处理应使用Fixes:标签指明引起回归的提交罪魁提交确定后大多数回归的修复应在两周内合入 mainline严重或影响面大的问题应在两三天内解决开发者普遍被鼓励优先处理回归相关工作并优先考虑直接回退罪魁提交这一最快速、最稳妥的修复方式。结语不引入回归是 Linux 内核开发的第一规则但它并非空洞的口号而是一套由规则、流程和工具共同支撑的完整体系用户侧通过[REGRESSION]报告 抄送回归邮件列表 regzbot 追踪将问题送入官方处理队列开发侧通过Closes:/Fixes:标签、优先修复与必要时回退让绝大多数回归在两周内得到解决。作为用户你只需要记住三件事用相似配置对比新旧内核、按规范提交报告、让 regzbot 看到你的报告——剩下的交给这套运转了数十年的成熟机制。【免费下载链接】linuxLinux kernel source tree项目地址: https://gitcode.com/GitHub_Trending/li/linux创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考