报告回归问题¶
“我们不造成回归问题”是 Linux 内核开发的第一条规则；Linux 创始人兼首席开发人员 Linus Torvalds 自己制定了这条规则，并确保它得到遵守。
本文档描述了该规则对用户的意义，以及 Linux 内核的开发模式如何确保解决所有报告的回归问题；与内核开发人员相关的方面留给 处理回归问题。
重点内容（又名“TL;DR”）¶
如果某个 Linux 内核运行良好，但较新版本运行较差或根本无法运行，则这是一个回归问题。请注意，较新的内核必须使用类似的配置进行编译；下面的详细解释更详细地描述了这一点和其他细则。
按照 报告问题 中概述的方式报告您的问题，它已经涵盖了回归问题的所有重要方面，并在下面重复以方便起见。其中两点很重要：在您报告的主题中以“[REGRESSION]”开头，并抄送或转发到 回归问题邮件列表 (regressions@lists.linux.dev)。
可选但建议：在发送或转发您的报告时，通过指定回归何时开始，让 Linux 内核回归跟踪机器人“regzbot”跟踪该问题，如下所示
#regzbot introduced: v5.13..v5.14-rc1
与用户相关的 Linux 内核回归问题的全部细节¶
重要的基础知识¶
什么是“回归问题”，什么是“无回归问题”规则？¶
如果某个应用程序或实际用例在某个 Linux 内核上运行良好，但在使用类似配置编译的较新版本上运行较差或根本无法运行，则这是一个回归问题。“无回归问题”规则禁止这种情况发生；如果意外发生这种情况，导致问题的开发人员应迅速修复该问题。
因此，当 Linux 5.13 中的 WiFi 驱动程序运行良好时，但 5.14 根本无法运行，运行速度明显较慢或出现异常行为时，这是一个回归问题。如果一个完美运行的应用程序突然在新内核版本中出现不稳定的行为，这也是一个回归问题；此类问题可能是由 procfs、sysfs 或 Linux 提供给用户空间软件的许多其他接口中的更改引起的。但请记住，如前所述：在本例中，5.14 需要使用与 5.13 类似的配置构建。这可以使用 make olddefconfig 来实现，如下面更详细的解释。
请注意本节第一句话中的“实际用例”：尽管有“无回归问题”规则，开发人员可以自由更改内核的任何方面，甚至可以更改 API 或 ABI 到用户空间，只要没有现有的应用程序或用例中断。
另请注意，“无回归问题”规则仅涵盖内核提供给用户空间的接口。因此，它不适用于内核内部接口，如模块 API，某些外部开发的驱动程序使用该接口来挂接到内核。
我如何报告回归问题？¶
只需按照 报告问题 中概述的方式报告问题，它已经描述了要点。以下方面在那里概述，对于回归问题尤其相关
在检查是否存在要加入的现有报告时，还要搜索 Linux 回归问题邮件列表的存档 和 regzbot 的 Web 界面。
在您报告的主题中以“[REGRESSION]”开头。
在您的报告中，清楚地提及上次运行良好的内核版本和第一个损坏的版本。理想情况下，尝试使用二分法找到导致回归问题的确切更改，如下面更详细的解释。
请记住让 Linux 回归问题邮件列表 (regressions@lists.linux.dev) 知道您的报告
如果您通过邮件报告回归问题，请抄送回归问题列表。
如果您将回归问题报告给某个错误跟踪器，请通过邮件将提交的报告转发到回归问题列表，同时抄送维护人员和相关子系统的邮件列表。
如果是稳定或长期系列中的回归问题（例如 v5.15.3..v5.15.5），请记住抄送 Linux 稳定邮件列表 (stable@vger.kernel.org)。
如果您成功执行了二分法，请将所有人在 CC 中添加到罪魁祸首的提交消息中，这些提交消息以“Signed-off-by:”开头的行提及。
在抄送以将您的报告转发到列表时，请考虑直接告诉上述 Linux 内核回归问题跟踪机器人您的报告。为此，请在您的邮件中包含如下段落
#regzbot introduced: v5.13..v5.14-rc1
Regzbot 然后会将您的邮件视为在指定的版本范围内引入的回归问题的报告。在上述情况下，Linux v5.13 仍然运行良好，Linux v5.14-rc1 是您遇到问题的第一个版本。如果您执行了二分法以查找导致回归问题的提交，请指定罪魁祸首的提交 ID，而不是
#regzbot introduced: 1f2e3d4c5d
放置这样的“regzbot 命令”符合您的利益，因为它将确保报告不会被忽略。如果您省略此操作，Linux 内核的回归问题跟踪器将负责告诉 regzbot 您的回归问题，只要您将副本发送到回归问题邮件列表。但回归问题跟踪器只是一个人，有时需要休息，或者偶尔甚至可能享受远离电脑的时间（听起来可能很疯狂）。因此，依靠此人会导致在回归问题在 跟踪和未解决的 Linux 内核回归问题列表 和 regzbot 发送的每周回归问题报告中被提及之前出现不必要的延迟。这些延迟可能导致 Linus Torvalds 在决定“继续开发还是完成并发布最终版本？”时无法意识到重要的回归问题。
是否真的修复了所有回归问题？¶
几乎所有回归问题都已修复，只要能够可靠地识别导致回归问题的更改（“罪魁祸首提交”）。有些回归问题可以在没有此更改的情况下修复，但通常需要此更改。
谁需要找到回归问题的根本原因？¶
受影响代码区域的开发人员应尝试自行查找罪魁祸首。但对于他们来说，这通常不可能以合理的努力来实现，因为很多问题只发生在开发人员无法触及的特定环境中 - 例如，特定的硬件平台、固件、Linux 发行版、系统配置或应用程序。这就是为什么最终通常由报告者来查找罪魁祸首提交；有时用户甚至可能需要在之后运行额外的测试，以查明确切的根本原因。开发人员应提供建议并在力所能及的范围内合理地提供帮助，以使典型用户相对容易且可以实现此过程。
我如何找到罪魁祸首？¶
执行二分法，如 报告问题 中粗略概述的那样，以及 二分回归问题 中更详细的描述。这听起来可能需要大量工作，但在很多情况下，它可以相对快速地找到罪魁祸首。如果难以或耗时地可靠地重现问题，请考虑与其他受影响的用户合作以共同缩小搜索范围。
在回归问题方面，我可以向谁寻求建议？¶
发送邮件到回归问题邮件列表 (regressions@lists.linux.dev)，同时抄送 Linux 内核的回归问题跟踪器 (regressions@leemhuis.info)；如果这个问题最好私下处理，请随意省略列表。
关于回归问题的更多细节¶
“无回归问题”规则的目标是什么？¶
用户在更新内核版本时应感到安全，而不必担心某些东西可能会中断。这符合内核开发人员的利益，可以使更新具有吸引力：他们不希望用户停留在已放弃或已超过一年半的稳定或长期 Linux 系列上。这符合每个人的利益，因为 这些系列可能存在已知的错误、安全问题或其他问题方面，这些问题已在更高版本中修复。此外，内核开发人员希望使用户能够简单而有吸引力地测试最新的预发布或常规版本。这也符合每个人的利益，因为如果在问题引入后不久就报告问题，则更容易跟踪和修复问题。
“无回归问题”规则在实践中是否真的被遵守？¶
它被非常认真地对待，从 Linux 创建者兼首席开发人员 Linus Torvalds 的许多邮件列表帖子中可以看出，其中一些帖子在 处理回归问题 中引用。
该规则的例外情况非常罕见；在过去，当开发人员认为某种情况需要例外情况时，他们几乎总是被证明是错误的。
谁确保“无回归问题”规则实际得到遵循？¶
子系统维护人员应负责处理，树维护人员会对其进行监视和支持 - 例如，Linus Torvalds 用于主线，Greg Kroah-Hartman 等人用于各种稳定/长期系列。
所有人都得到了一些人的帮助，他们试图确保没有回归问题报告被忽略。其中一人是 Thorsten Leemhuis，他目前担任 Linux 内核的“回归问题跟踪器”；为了方便这项工作，他依赖于 regzbot，即 Linux 内核回归问题跟踪机器人。这就是为什么您要通过抄送或将每个报告转发到回归问题邮件列表，最好在您的邮件中使用“regzbot 命令”以立即对其进行跟踪，从而将您的报告引起这些人的注意。
回归问题通常多久修复一次？¶
开发人员应尽快修复任何报告的回归问题，以便及时为受影响的用户提供解决方案，并防止更多用户遇到该问题；但是，开发人员需要花费足够的时间和精力来确保回归问题修复不会造成额外的损害。
因此，答案取决于各种因素，例如回归问题的影响、年龄或发生回归问题的 Linux 系列。但最终，大多数回归问题应在两周内修复。
如果可以通过更新某些软件来避免该问题，这是一个回归问题吗？¶
几乎总是：是的。如果开发人员告诉您其他情况，请按照上述方式向回归问题跟踪器寻求建议。
如果较新的内核运行速度较慢或消耗更多能量，这是一个回归问题吗？¶
是的，但差异必须是显着的。因此，微基准测试中 5% 的速度下降不太可能被视为回归问题，除非它也使广泛基准测试的结果受到超过 1% 的影响。如果有疑问，请寻求建议。
如果在更新 Linux 时外部内核模块中断，这是一个回归问题吗？¶
不是，因为“无回归问题”规则是关于 Linux 内核提供给用户空间的接口和服务。因此，它不涵盖构建或运行外部开发的内核模块，因为它们在内核空间中运行并使用偶尔更改的内部接口挂接到内核。
由安全修复引起的回归问题如何处理？¶
在极少数情况下，如果不造成回归问题，则无法修复安全问题；这些修复会采取措施，因为它们最终是两害相权取其轻。幸运的是，几乎总是可以避免这种中间情况，因为受影响区域的关键开发人员，通常甚至是 Linus Torvalds 本人，都会尽力修复安全问题，而不会造成回归问题。
如果您仍然遇到这种情况，请检查邮件列表存档，看看人们是否尽力避免回归问题。如果不是，请报告；如果有疑问，请按照上述方式寻求建议。
如果修复回归问题不可能而不造成另一个回归问题，会发生什么？¶
遗憾的是，这些事情会发生，但幸运的是，发生的频率不高；如果发生这些事情，受影响代码区域的专家开发人员应调查该问题，以找到避免回归问题或至少避免其影响的修复方法。如果您遇到这种情况，请执行已为安全修复引起的回归问题概述的操作：检查早期讨论，看看人们是否已经尽力而为，如果有疑问，请寻求建议。
在此快速说明：如果人们定期对每个开发周期的主线预发布版本（例如 v5.15-rc1 或 -rc3）进行测试运行，则可以避免这些情况。最好通过想象 Linux v5.14 和 v5.15-rc1 之间集成的更改来解释这一点，该更改导致回归问题，但同时是应用于 5.15-rc1 的某些其他改进的硬性要求。如果在 5.15 发布之前有人发现并报告了所有这些更改，则通常可以简单地恢复这些更改，从而解决了回归问题。几天或几周后，此解决方案可能变得不可能，因为某些软件可能已经开始依赖于后续更改之一引入的方面：恢复所有更改将导致所述软件的用户出现回归问题，因此不可能这样做。
如果我所依赖的某些功能在几个月前被删除，这是一个回归问题吗？¶
是的，但由于上一节中概述的方面，通常很难修复此类回归问题。因此，需要根据具体情况进行处理。这是为什么每个人都应定期测试主线预发布版本的另一个原因。
如果我似乎是唯一受影响的人，“无回归问题”规则是否适用？¶
是的，但仅适用于实际用途：Linux 开发人员希望可以自由删除仅在阁楼和博物馆中找到的硬件支持。
请注意，有时无法避免回归问题以取得进展 - 并且需要后者以防止 Linux 停滞不前。因此，如果只有极少数用户似乎受到回归问题的影响，为了更大的利益，让他们通过并符合他们和其他每个人的利益。特别是如果有一种简单的方法可以以某种方式规避回归问题，例如通过更新某些软件或使用专门为此目的创建的内核参数。
回归问题规则是否也适用于暂存树中的代码？¶
根据 涵盖所有暂存代码的配置选项的帮助文本，自早期以来就声明
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.
暂存开发人员仍然经常遵守“无回归问题”规则，但有时会弯曲该规则以取得进展。例如，这就是为什么当暂存树中的 WiFi 驱动程序被从头开始编写的完全不同的驱动程序替换时，某些用户不得不处理（通常可以忽略不计）回归问题。
为什么稍后版本必须“使用类似的配置编译”？¶
因为 Linux 内核开发人员有时会集成已知会导致回归问题的更改，但使它们成为可选的，并在内核的默认配置中禁用它们。这种技巧允许取得进展，因为“无回归问题”规则否则会导致停滞。
例如，考虑一种新的安全功能，该功能阻止访问某些经常被恶意软件滥用的内核接口，但同时需要这些接口才能运行一些很少使用的应用程序。概述的方法使双方都满意：使用这些应用程序的人可以关闭新的安全功能，而其他所有人都可以启用它而不会遇到麻烦。
如何创建与旧内核类似的配置？¶
使用已知的良好内核启动您的机器，并使用 make olddefconfig 配置较新的 Linux 版本。这使内核的构建脚本从正在运行的内核中选取配置文件（“.config”文件）作为您将要编译的新内核的基础；之后，它们将所有新配置选项设置为其默认值，这应禁用可能导致回归问题的新功能。
我可以报告使用预编译的 vanilla 内核发现的回归问题吗？¶
您需要确保较新的内核是使用与旧内核类似的配置文件编译的（请参阅上文），因为构建这些内核的人可能为较新的内核启用了某些已知不兼容的功能。如果有疑问，请将此事报告给内核提供商并寻求建议。
有关使用“regzbot”进行回归问题跟踪的更多信息¶
什么是回归问题跟踪，为什么我应该关心它？¶
像“无回归问题”这样的规则需要有人确保它们得到遵循，否则它们会被意外或故意破坏。历史表明，对于 Linux 内核开发也是如此。这就是为什么 Linux 内核的回归问题跟踪器 Thorsten Leemhuis 和一些人试图确保所有回归问题都得到修复，方法是密切关注这些问题，直到它们得到解决。他们都没有为此付费，因此这项工作是在尽最大努力的基础上完成的。
为什么以及如何使用机器人跟踪 Linux 内核回归问题？¶
由于 Linux 内核开发过程的分布式和松散结构性质，完全手动地跟踪回归问题已被证明非常困难。这就是为什么 Linux 内核的回归问题跟踪器开发了 regzbot 以方便工作，其长期目标是尽可能地为所有相关人员自动化回归问题跟踪。
Regzbot 通过监视对跟踪的回归问题报告的回复来工作。此外，它还在查找发布的或提交的补丁，这些补丁通过“Link:”标记引用此类报告；也会跟踪对此类补丁发布的回复。结合起来，这些数据可以很好地了解修复过程的当前状态。
如何查看 regzbot 当前跟踪哪些回归问题？¶
查看 regzbot 的 Web 界面。
哪些类型的问题应该由 regzbot 跟踪？¶
该机器人旨在跟踪回归问题，因此请不要让 regzbot 参与常规问题。但是，如果您让 regzbot 跟踪严重问题，例如关于挂起、数据损坏或内部错误（Panic、Oops、BUG()、警告等）的报告，则对于 Linux 内核的回归问题跟踪器来说是可以的。
如何更改跟踪的回归问题的方面？¶
通过在直接或间接回复包含报告的邮件时使用“regzbot 命令”。最简单的方法：在您的“已发送”文件夹或邮件列表存档中找到报告，然后使用您的邮件程序的“全部回复”功能回复它。在该邮件中，在独立的段落中使用以下命令之一（IOW：使用空行将这些命令中的一个或多个与邮件文本的其余部分分开）。
更新回归问题何时开始发生，例如在执行二分法之后
#regzbot introduced: 1f2e3d4c5d设置或更新标题
#regzbot title: foo监视讨论或 bugzilla.kernel.org 工单，其中讨论了该问题或修复的其他方面：
#regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789指向包含感兴趣的更多细节的地方，例如邮件列表帖子或错误跟踪器中的工单，它们与该问题略有相关，但关于不同的主题
#regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789将回归问题标记为无效
#regzbot invalid: wasn't a regression, problem has always existed
Regzbot 支持一些主要由开发人员或跟踪回归问题的人员使用的其他命令。可以在 入门指南 和 regzbot 的参考文档 中找到它们以及有关上述 regzbot 命令的更多详细信息。