英语

报告回归问题¶

“我们不会引起回归”是 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)。

如果您成功执行了二分法，请将所有人的抄送到以 “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 内核报告我发现的回归吗？¶

您需要确保较新的内核使用与较旧内核类似的配置文件进行编译（请参阅上文），因为构建它们的那些人可能为较新的内核启用了一些已知不兼容的功能。如果有疑问，请将此事报告给内核的提供商并寻求建议。

Linux 内核

目录

本页