处理回归 【ChatGPT】

• https://www.kernel.org/doc/html/v6.6/process/handling-regressions.html#

处理回归

我们不会引起回归 - 本文描述了对开发人员来说，“Linux内核开发的第一法则”在实践中意味着什么。它是对报告回归的补充，该报告从用户的角度涵盖了这个主题；如果你从未阅读过那篇文章，至少在继续阅读本文之前去浏览一下。

重要内容（又名“太长不看”）

• 确保回归邮件列表的订阅者（regressions@lists.linux.dev）迅速了解任何新的回归报告：

  • 收到未抄送列表的邮件报告时，立即通过“回复所有”方式将其抄送给列表。

  • 将在错误跟踪器中提交的任何报告转发或反弹到列表。

• 使Linux内核回归跟踪机器人“regzbot”跟踪该问题（这是可选的，但建议）：

  • 对于邮件报告，请检查报告者是否包含了类似#regzbot introduced v5.13..v5.14-rc1的行。如果没有，发送一个回复（抄送回归列表），其中包含以下段落，告诉regzbot问题开始发生的时间：

  	#regzbot ^introduced 1f2e3d4c5b6a
  

  • 将错误跟踪器中的报告转发到回归列表（参见上文），包括以下段落：

  #regzbot introduced: v5.13..v5.14-rc1
  #regzbot from: Some N. Ice Human <some.human@example.com>
  #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
  

• 在提交回归修复时，向补丁描述添加“Link:”标签，指向问题报告的所有位置，如《提交补丁：将您的代码纳入内核的基本指南》和《文档/流程/5.Posting.rst》所规定的。

• 一旦确定问题的罪魁祸首，尽快修复回归；大多数回归的修复应在两周内合并，但有些需要在两到三天内解决。

所有与开发人员相关的Linux内核回归的详细信息

更详细的重要基础知识

收到回归报告时该怎么办

确保Linux内核的回归跟踪器和其他回归邮件列表的订阅者（regressions@lists.linux.dev）了解任何新报告的回归：

• 当您收到未抄送列表的报告时，请立即通过发送至少简短的“回复所有”方式将其抄送给列表；尽量确保在回复省略了列表的回复时再次抄送列表。

• 如果错误跟踪器中提交的报告出现在您的收件箱中，请将其转发或反弹到列表。在这之前，考虑检查列表存档，如果报告者已按照报告问题的指示转发了报告。

在执行任何操作时，考虑立即让Linux内核回归跟踪机器人“regzbot”开始跟踪该问题：

• 对于邮件报告，请检查报告者是否包含了“regzbot命令”，如#regzbot introduced 1f2e3d4c5b6a。如果没有，请发送一个回复（抄送回归列表），其中包含以下段落：

  #regzbot ^introduced: v5.13..v5.14-rc1

  这告诉regzbot问题开始发生的版本范围；您也可以使用提交ID指定范围，或者在报告者进行二分查找确定罪魁祸首的情况下，说明单个提交ID。

  注意“introduced”前的插入符（^），它告诉regzbot将父邮件（您回复的邮件）视为您想要跟踪的回归的初始报告；这很重要，因为regzbot稍后将寻找带有指向lore.kernel.org存档中报告的“Link:”标签的补丁。

• 在将错误跟踪器中的回归报告转发到错误列表时，包括以下带有这些regzbot命令的段落：

  #regzbot introduced: 1f2e3d4c5b6a
  #regzbot from: Some N. Ice Human <some.human@example.com>
  #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789
  

  Regzbot将自动将包含指向您的邮件或所提及的票证的“Link:”标签的补丁与报告关联起来。

修复回归时的重要事项

在提交回归修复时，您无需做任何特殊操作，只需记住提交补丁：将您的代码纳入内核、文档/流程/5.Posting.rst和《您想知道的有关Linux稳定版本的一切》中更详细地解释的内容：

• 使用“Link:”标签指向问题报告的所有位置：

  Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
  Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890
  

• 添加一个“Fixes:”标签，指定引起回归的提交。

• 如果罪魁祸首在较早的开发周期中合并，明确标记修复以进行后向移植，使用Cc: stable@vger.kernel.org标签。

所有这些都是您应该做的，并且在处理回归时非常重要，因为这些标签对于可能在几周、几个月或几年后查看问题的每个人（包括您在内）都具有很大的价值。这些标签对其他内核开发人员或Linux发行版使用的工具和脚本也至关重要；其中一个工具是regzbot，它严重依赖于“Link:”标签来将回归报告与解决它们的更改关联起来。

对于修复回归的期望和最佳实践

作为Linux内核开发人员，您应该尽力避免以下情况：由于您最近的更改导致的回归，用户只能选择以下选项之一：

• 运行受影响的内核回归。

• 切换到较旧或较新的内核系列。

• 在确定回归罪魁祸首后的三周内继续运行过时且可能不安全的内核。最好是少于两周。如果问题严重或影响到许多用户，应该只有几天。

如何在实践中实现这一点取决于各种因素。请使用以下经验法则作为指南。

总体而言：

• 优先处理回归，而不是其他所有Linux内核工作，除非后者涉及严重问题（例如急性安全漏洞、数据丢失、硬件损坏等）。

• 加快处理最近进入适当的主线、稳定或长期版本的主线回归。不要认为当前周期的回归可以等到周期结束，因为该问题可能会阻止用户和CI系统现在或一般地测试主线。

• 务必小心操作，以避免额外或更大的损害，即使解决问题可能需要比下面概述的时间更长。

一旦确定回归的罪魁祸首：

• 如果问题严重或影响到许多用户（一般或在特定硬件环境、发行版或稳定/长期系列中），请在两到三天内将修复合并到主线。

• 如果罪魁祸首最近进入适当的主线、稳定或长期版本（直接或通过后向移植），请在接下来的周日之前将修复合并到主线；如果罪魁祸首在一周早期就已知晓并且很容易解决，请尽量在同一周内将修复合并到主线。

• 对于其他回归，请在接下来的三周内的最后一个周日之前将修复合并到主线。如果回归是人们可以轻松忍受一段时间的问题（例如轻微的性能回归），则可以接受在一两个周日后合并修复。强烈不建议延迟将回归修复合并到下一个合并窗口，除非修复非常危险，或者罪魁祸首在一年前就已合并到主线。

在程序上：

• 总是考虑回滚罪魁祸首，因为这通常是修复回归的最快、最安全的方法。不要担心稍后将修复的变体合并到主线：这应该是直截了当的，因为大部分代码已经经过审查。

• 尽量在当前开发周期结束前解决在主线引入的任何回归，除非修复具有异常风险。

• 如果回归看起来复杂，请考虑在讨论或补丁审查中抄送Linus。在危险或紧急情况下也要抄送，特别是如果子系统维护者不可用。当您知道这样的回归已进入主线、稳定或长期版本时，也要抄送稳定团队。

• 对于紧急回归，考虑要求Linus直接从邮件列表中提取修复：对于不具争议的修复，他完全可以接受这样做。但最好是这样的请求应该与子系统维护者协调，或直接由他们提出。

• 如果您不确定修复在新的主线发布前几天是否值得冒风险，发送一封邮件给Linus，抄送通常的列表和相关人员；在邮件中，总结情况，询问他是否考虑直接从列表中提取修复。他自己可以做出决定，必要时甚至可以推迟发布。这样的请求最好也应该与子系统维护者协调，或直接由他们提出。

关于稳定和长期内核：

• 如果回归在任何时候都没有出现在主线，或者已在主线中修复，您可以将回归留给稳定团队。

• 如果在过去的十二个月内的适当的主线版本中出现了回归，请确保使用“Cc: stable@vger.kernel.org”标签标记修复，因为仅有“Fixes:”标签并不能保证后向移植。如果您知道罪魁祸首已经被后向移植到稳定或长期内核中，请添加相同的标签。

• 当收到关于最近稳定或长期内核系列中的回归的报告时，请至少简要评估该问题是否可能在当前主线中发生，如果可能，请处理该报告。如果有疑问，请要求报告者检查主线。

• 每当您希望迅速解决最近也进入适当的主线、稳定或长期版本的回归时，请在主线中快速修复；在适当的情况下，因此要快速跟踪修复（见上文）涉及Linus。这是因为稳定团队通常不会回滚或修复在主线中引起相同问题的任何更改。

关于补丁流程：

• 开发人员在努力达到上述时间段时，请记住考虑到获取修复进行测试、审查和由Linus合并所需的时间，确保他人适当处理紧急修复。

• 审查人员，您被要求及时审查回归修复，以协助开发人员达到上述时间段。

• 子系统维护者，您也被鼓励加快处理回归修复。因此，请评估是否可以跳过linux-next来处理特定修复。在需要时考虑更频繁地发送git拉取请求。并尽量避免在周末持有回归修复，特别是当修复标记为后向移植时。

关于回归开发者应该注意的更多方面

如何处理已知存在回归风险的变更

评估回归风险的大小，例如通过在Linux发行版和Git forges中进行代码搜索来进行。还要考虑询问其他可能受到影响的开发者或项目来评估甚至测试所提出的变更；如果出现问题，也许可以找到一个对所有人都可以接受的解决方案。

如果最终回归风险似乎相对较小，那就继续进行变更，但要让所有相关方知道风险。因此，请确保您的补丁描述明显表明这一方面。一旦变更合并，告诉Linux内核的回归跟踪器和回归邮件列表有关风险的信息，这样每个人都可以在出现报告时关注变更。根据风险的大小，您还可能希望要求子系统维护者在其主线拉取请求中提及该问题。

关于回归还有什么需要了解的？

查看《报告回归》，它涵盖了您可能想要了解的许多其他方面：

• "无回归规则"的目的
• 实际符合回归资格的问题
• 谁负责找到回归的根本原因
• 如何处理棘手的情况，例如回归是由安全修复引起的，或者修复回归可能会引发另一个问题

当涉及到回归时应该向谁寻求建议

发送邮件到回归邮件列表（regressions@lists.linux.dev），同时抄送Linux内核的回归跟踪器（regressions@leemhuis.info）；如果问题最好在私下解决，可以随意省略列表。

关于回归跟踪和regzbot的更多信息

为什么Linux内核有一个回归跟踪器，以及为什么使用regzbot？

像"无回归"这样的规则需要有人来确保它们得到遵守，否则它们会被意外地或故意地打破。历史已经证明这对Linux内核也是如此。这就是为什么Thorsten Leemhuis自愿担任Linux内核的回归跟踪器，他偶尔会得到其他人的帮助。他们都没有为此付费，这就是为什么回归跟踪是基于最大的努力来完成的。

早期手动跟踪回归的尝试表明这是一项令人筋疲力尽和令人沮丧的工作，因此在一段时间后被放弃了。为了防止这种情况再次发生，Thorsten开发了regzbot来简化工作，长期目标是尽可能地自动化回归跟踪，让所有相关人员受益。

回归跟踪如何与regzbot一起工作？

该机器人会监视对已跟踪回归的报告的回复。此外，它还会关注发布或提交的补丁，其中包含指向这些报告的"Link:"标签；对这些补丁发布的回复也会被跟踪。综合这些数据可以很好地了解修复过程的当前状态。

Regzbot试图以尽可能少的开销来完成其工作，对于报告者和开发者来说，实际上只有报告者需要承担额外的责任：他们需要使用上面介绍的#regzbot命令告诉regzbot有关回归报告；如果他们没有这样做，其他人可以使用#regzbot ^introduced来处理。

对于开发者来说，通常不需要额外的工作，他们只需要确保做一些在regzbot出现之前就已经预期的事情：在指向有关已解决问题的所有报告的补丁描述中添加"Link:"标签。

我必须使用regzbot吗？

如果您使用，对每个人都有利，因为内核维护者如Linus Torvalds部分依赖regzbot的跟踪工作--例如在决定发布新版本或延长开发阶段时。为此，他们需要了解所有未解决的回归；为了做到这一点，众所周知，Linus会查看regzbot每周发送的报告。

我必须告诉regzbot我发现的每个回归吗？

理想情况下是：我们都是人类，当突然出现更重要的问题时很容易忘记问题--例如Linux内核中的更大问题或现实生活中让我们有段时间远离键盘的事情。因此，最好是告诉regzbot每个回归，除非您立即编写修复程序并将其提交到定期合并到受影响的内核系列的树中。

如何查看regzbot当前跟踪的回归？

查看regzbot的Web界面以获取最新信息；或者，搜索最新的回归报告，regzbot通常在每周日晚上（协调世界时）发送一次，这是Linus通常发布新（预）发布的几个小时前。

regzbot正在监视哪些地方？

Regzbot正在监视最重要的Linux邮件列表，以及linux-next、mainline和stable/longterm的git存储库。

regzbot应该跟踪什么样的问题？

该机器人旨在跟踪回归，因此请不要让regzbot参与常规问题。但是对于Linux内核的回归跟踪器来说，如果您使用regzbot跟踪严重问题，比如关于挂起、数据损坏或内部错误（Panic、Oops、BUG()、警告等）的报告，那是可以的。
我可以将CI系统发现的回归添加到regzbot的跟踪中吗？

如果特定的回归可能对实际使用情况产生影响，因此可能会被用户注意到，那么请随时这样做；因此，请不要让regzbot参与不太可能在实际使用中出现的理论回归。

如何与regzbot进行交互？

通过在回复回归报告的直接或间接回复中使用“regzbot命令”来实现。这些命令需要单独成段（即它们需要使用空行与邮件的其余部分分隔开）。

其中一个这样的命令是#regzbot introduced <version or commit>，这使得regzbot将您的邮件视为添加到跟踪中的回归报告，就像上面已经描述的那样；#regzbot ^introduced <version or commit>是另一个这样的命令，它使得regzbot将父邮件视为一个开始跟踪的回归报告。

一旦使用了这两个命令中的一个，其他regzbot命令可以在直接或间接回复报告中使用。您可以在介绍命令的下方或回复使用了其中一个命令的邮件或其本身是对该邮件的回复时编写它们：

• 设置或更新标题：

  #regzbot title: foo

• 监视讨论或bugzilla.kernel.org票据，其中讨论了问题的附加方面或修复 -- 例如发布修复回归的补丁：

  #regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/

  监视仅适用于lore.kernel.org和bugzilla.kernel.org；regzbot将考虑该线程或票据中的所有消息与修复过程相关。

• 指向一个具有进一步相关细节的地方，比如一个邮件列表帖子或一个与不同主题相关但略有关联的bug跟踪器中的票据：

  #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789

• 标记一个回归为已由上游提交或已经落地的提交修复：

  #regzbot fixed-by: 1f2e3d4c5d

• 将一个回归标记为已由regzbot跟踪的另一个回归的重复：

  #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/

• 将一个回归标记为无效：

  #regzbot invalid: 不是回归，问题一直存在

关于regzbot及其命令还有什么需要告诉的吗？

关于Linux内核回归跟踪机器人的更详细和最新信息可以在其项目页面上找到，其中包括入门指南和参考文档，两者都涵盖了比上面部分更多的细节。

Linus关于回归的引用

以下是Linus Torvalds对于如何处理回归的一些现实例子：

• 来自2017-10-26（1/2）：

    如果你破坏了现有的用户空间设置，那就是一个回归。
  
    说“但我们会修复用户空间设置”是不可以的。
  
    真的。不可以。
  
    [...]
  
    第一条规则是：
  
     - 我们不会引起回归
  
    推论是，当回归*确实*发生时，我们承认它们并修复它们，而不是责怪用户空间。
  
    你们显然已经否认了这个回归三个星期了，这意味着我会回滚，并且我会停止拉取apparmor请求，直到涉及的人了解内核开发是如何进行的。
  

• 来自2017-10-26（2/2）：

    人们基本上应该总是觉得他们可以更新他们的内核而不必担心。
  
    我拒绝引入“你只能在更新内核的同时也更新那个其他程序”的限制。如果内核以前对你有用，规则就是它继续对你有用。
  
    也许有例外，但它们寥寥无几，它们通常有一些主要和根本的原因，基本上是完全不可避免的，人们_努力_避免它们。也许我们实际上不再能够支持几十年前的硬件，并且没有人再使用它与现代内核。也许我们在如何做事情上存在严重的安全问题，人们实际上依赖于那个基本上是有缺陷的模型。也许还有其他一些基本的破坏，它们只是_必须_有一个非常核心和基本的原因。
  
    请注意，这实际上非常关于*破坏*人们的环境。
  
    行为变化会发生，也许我们不再支持某些功能。在/proc/<pid>/stat中有一些字段被打印为零，仅仅是因为它们在内核中不再存在，或者因为显示它们是一个错误（通常是信息泄漏）。但数字被零替换了，所以以前用于解析字段的代码仍然有效。用户可能看不到他们以前看到的一切，因此行为显然是不同的，但事情仍然_工作_，即使它们可能不再显示敏感（或不再相关）的信息。
  
    但如果某些东西实际上破坏了，那么改变必须得到修复或回滚。它在*内核*中得到修复。而不是说“好吧，修复你的用户空间”。是内核的改变暴露了问题，它需要是内核来纠正它，因为我们有一个“就地升级”的模型。我们没有“与新用户空间升级”的模型。
  
    我严肃地拒绝接受那些不理解和尊重这个非常简单规则的人的代码。
  
    这个规则也不会改变。
  
    是的，我意识到内核在这方面是“特殊的”。我为此感到自豪。
  
    我已经看到，并且可以指出，很多项目都会说“我们需要破坏那个用例才能取得进展”或“你依赖于未记录的行为，那就是你的问题”或“有更好的方法来做你想做的事情，你必须改变到那个新的更好的方法”，我简直不认为这在非常早期的alpha版本之外是可以接受的，那些有实验性用户知道他们签署了什么的版本。在过去的二十年里，内核并不处于那种情况。
  
    我们在内核内部一直会有API破坏。我们会通过说“现在你需要做XYZ”来解决内部问题，但那是关于内部内核API的，然后做那些事情的人显然也必须修复所有使用该API的内核内部用户。没有人能说“我现在破坏了你使用的API，现在_你_需要修复它”。无论谁破坏了什么东西，都必须修复它。
  
    而我们根本不会破坏用户空间。
  

• 从2020-05-21：

  关于回归的规则从来都不是关于任何形式的记录行为，或者代码所在的位置。

  关于回归的规则总是关于“破坏用户工作流程”。

  用户是唯一重要的事情。

  无论“你不应该使用这个”还是“那个行为是未定义的，你的应用程序崩溃是你自己的错”或者“那只是因为内核错误而工作”，这些都不相关。

  现实从来都不是非黑即白的。所以我们有一些像“严重的安全问题”之类的东西，这迫使我们做出可能破坏用户空间的更改。但即使如此，规则也是我们没有其他选择，可以让事情继续进行。

  显然，如果用户花了几年甚至都没有注意到某些东西出错，或者我们有合理的方法来解决这个问题，对用户来说不会带来太多麻烦（比如“好吧，只有少数几个用户，他们可以使用内核命令行来解决这个问题”之类的事情），我们也会放松一些。

  但是，“那是被记录为出错的”（无论是因为代码在暂存区还是因为手册中说了其他的东西）是无关紧要的。如果暂存区的代码如此有用以至于人们最终开始使用它，那意味着它基本上是带有“请清理这个”的标志的常规内核代码。

  另一方面，谈论“API稳定性”的人完全是错误的。API也不重要。你可以对API进行任何更改-只要没有人注意到。

  再次强调，回归规则不是关于文档，不是关于API，也不是关于月亮的阶段。

  它完全是关于“我们给用户空间带来了问题，而这些问题以前是正常工作的”。

• 从2017-11-05：

  我们的回归规则从来都不是“行为不变”。那意味着我们根本不能做任何更改。

  例如，我们经常做一些诸如添加新的错误处理等事情，有时甚至在我们的kselftest目录中添加测试。

  所以显然行为经常发生变化，我们并不认为这是一个回归。

  内核的回归规则是某个真实用户工作流程的中断。不是某个测试。不是“看，我以前能做X，现在不能做了”。

• 从2018-08-03：

  你忽略了第一条内核规则。

  我们不会回归，而且我们不会回归，正是因为你完全错了。

  而且你为你的观点提出的理由实际上正是你错的原因。

  你的“好理由”纯粹是垃圾。

  “我们不回归”的整个意义在于人们可以升级内核而不必担心它。

  内核有一个已经修复的错误

  这完全不重要。

  伙计们，某个东西是否有错误根本不重要。

  为什么？

  错误是常有的。这是生活的事实。争论“我们必须破坏某些东西，因为我们正在修复一个错误”是完全疯狂的。我们每天修复数十个错误，认为“修复一个错误”意味着我们可以破坏某些东西是完全错误的。

  所以错误根本不相关于讨论。它们发生，它们被发现，它们被修复，这与“我们破坏用户”无关。

  因为唯一重要的是用户。

  这有多难理解？

  任何将“但它有错误”作为论点的人完全没有理解到点子上。就用户而言，它没有错误-它对他/她来说是工作的。

  也许它之所以工作是因为用户已经考虑到了这个错误，也许它之所以工作是因为用户没有注意到-再次强调，这并不重要。它对用户来说是工作的。

  为了“错误”而破坏用户工作流程绝对是最糟糕的原因。

  这基本上是在说“我拿一个工作的东西，然后我破坏了它，但现在它更好了”。你难道看不出这种说法有多么疯狂吗？

  没有用户，你的程序不是一个程序，它只是一段毫无意义的代码，你可以扔掉它。

  真的。这就是为什么内核开发的第一条规则是“我们不破坏用户”。因为“我修复了一个错误”绝对不是一个论点，如果这个错误修复破坏了用户的设置。通过“修复”明显用户根本不关心的东西，你实际上引入了一个更大的错误。

  而且该死的，我们一直在升级内核，而不需要升级任何其他程序。这是绝对必要的，因为标志日和依赖关系非常糟糕。

  而且这也是必需的，仅仅因为作为内核开发人员，我不会升级我根本不关心的其他随机工具，我希望我的任何用户在同一时间感到安全。

  所以不。你的规则完全错误。如果你不能升级内核而不升级其他一些随机的二进制文件，那我们就有问题了。

• 从2021-06-05：

  没有关于回归的有效论点。

  老实说，安全人员需要明白，“不工作”不是安全的成功案例。这是一个失败案例。

  是的，“不工作”可能是安全的。但在这种情况下，安全是毫无意义的。

• 从2011-05-06（1/3）：

  二进制兼容性更重要。

  如果二进制文件不使用接口来解析格式（或者只是错误地解析-参见最近的一个例子，将uuid添加到/proc/self/mountinfo），那就是一个回归。

  回归会被撤销，除非存在安全问题或类似问题，使我们说“哦，天哪，我们真的必须破坏一些东西”。

  我不明白为什么这个简单的逻辑对一些内核开发人员来说如此困难。现实很重要。你个人的愿望根本不重要。

  如果你创建了一个可以在不解析接口描述的情况下使用的接口，那么我们就必须使用这个接口。理论根本不重要。

  你可以帮助修复工具，并尽量避免兼容性问题。这样的问题并不多。

• 从2011-05-06（2/3）：

  很明显，它不是一个内部的跟踪点。根据定义。它被powertop使用。

• 2011-05-06 (3/3)：

  我们有一些使用该ABI的程序，因此如果它们出现问题，就会导致回归。

• 2012-07-06：

  现在这让我想知道Debian的_unstable_是否真的符合标准的发行版用户空间。

  哦，如果内核破坏了一些标准的用户空间，那就算是。有很多人在运行Debian的unstable版本。

• 2019-09-15：

  一个特别临时的回退是最顶部的提交（忽略版本更改本身），就在发布之前完成的，虽然这非常令人恼火，但也许也具有教育意义。

  有教育意义的是，我回退了一个实际上并没有错误的提交。事实上，它正是在做它本来要做的事情，并且做得非常好。事实上，它做得非常好，以至于它引起的大幅改进的IO模式随后揭示了由于一个完全无关的领域中的真正错误而导致的用户可见的回归。

  实际的回归细节并不是我指出这个回退具有教育意义的原因，尽管如此。更重要的是，这是一个有教育意义的例子，说明了什么算是回归，以及整个“没有回归”的内核规则意味着什么。回退的提交没有改变任何API，也没有引入任何新的错误。但它最终暴露了另一个问题，因此导致了用户的内核升级失败。所以它被回退了。

  这里的重点是，我们基于用户报告的行为进行回退，而不是基于某种“它改变了ABI”或“它引起了错误”的概念。问题实际上是已经存在的，只是之前没有触发而已。由于变更引入的更好的IO模式刚好暴露了一个旧错误，并且人们已经依赖于以前的旧问题的良性行为。

  不要担心，一旦我们决定如何处理我们与人们刚好依赖于偶然行为的接口发生了不良互动的事实，我们将重新引入改进IO模式的修复（也许甚至作为稳定补丁进行回溯）。只是在此期间，我回退了这个为本次发布向用户暴露问题的东西，即使我希望它会被重新引入。

  从整个事情中得到的启示是，这不是关于你是否改变了内核用户空间ABI，或者修复了一个错误，或者关于旧代码“本来就不应该在第一次工作”。而是关于某些东西是否破坏了现有用户的工作流程。

  无论如何，这是我对整个回归问题的小插曲。因为这是“内核编程的第一法则”，我觉得值得偶尔提一提。