Back to home page

OSCL-LXR

 
 

    


0001 .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0)
0002 .. 【重分发信息参见本文件结尾】
0003 
0004 .. include:: ../disclaimer-zh_CN.rst
0005 
0006 :Original: Documentation/admin-guide/reporting-regressions.rst
0007 
0008 :译者:
0009 
0010  吴想成 Wu XiangCheng <bobwxc@email.cn>
0011 
0012 
0013 ============
0014 报告回归问题
0015 ============
0016 
0017 “*我们拒绝出现回归*”是Linux内核开发的首要规则;Linux的发起者和领军开发者Linus
0018 Torvalds立下了此规则并确保它被落实。
0019 
0020 本文档描述了这条规则对用户的意义,以及Linux内核开发模型如何确保解决所有被报告
0021 的回归;关于内核开发者如何处理的方面参见 Documentation/process/handling-regressions.rst 。
0022 
0023 
0024 本文重点(亦即“太长不看”)
0025 ==========================
0026 
0027 #. 如果某程序在原先的Linux内核上运行良好,但在较新版本上效果更差、或者根本不
0028    能用,那么你就碰见回归问题了。注意,新内核需要使用类似配置编译;更多相关细
0029    节参见下方。
0030 
0031 #. 按照 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst 中
0032    所说的报告你的问题,该文档已经包含了所有关于回归的重要方面,为了方便起见也
0033    复制到了下面。两个重点:在报告主题中使用“[REGRESSION]”开头并抄送或转发到
0034    `回归邮件列表 <https://lore.kernel.org/regressions/>`_
0035    (regressions@lists.linux.dev)。
0036 
0037 #. 可选但是建议:在发送或转发报告时,指明该回归发生的起点,以便Linux内核回归
0038    追踪机器人“regzbot”可以追踪此问题::
0039 
0040        #regzbot introduced v5.13..v5.14-rc1
0041 
0042 
0043 与用户相关的所有Linux内核回归细节
0044 =================================
0045 
0046 
0047 基本重点
0048 --------
0049 
0050 
0051 什么是“回归”以及什么是“无回归规则”?
0052 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0053 
0054 如果某程序/实例在原先的Linux内核上运行良好,但在较新版本上效果更差、或者根本
0055 不能用,那么你就碰见回归问题了。“无回归规则”不允许出现这种情况。如果偶然发
0056 生了,导致问题的开发者应当迅速修复问题。
0057 
0058 也就是说,若Linux 5.13中的WiFi驱动程序运行良好,但是在5.14版本上却不能用、速
0059 度明显变慢或出现错误,那就出现了回归。如果某正常工作的应用程序突然在新内核上
0060 出现不稳定,这也是回归;这些问题可能是由于procfs、sysfs或Linux提供给用户空间
0061 软件的许多其他接口之一的变化。但请记住,前述例子中的5.14需要使用类似于5.13的
0062 配置构建。这可以用 ``make olddefconfig`` 实现,详细解释见下。
0063 
0064 注意本节第一句话中的“实例”:即使开发者需要遵循“无回归”规则,但仍可自由地改
0065 变内核的任何方面,甚至是导出到用户空间的API或ABI,只要别破坏现有的应用程序或
0066 用例。
0067 
0068 还需注意,“无回归”规则只限制内核提供给用户空间的接口。它不适用于内核内部接
0069 口,比如一些外部开发的驱动程序用来插入钩子到内核的模块API。
0070 
0071 如何报告回归?
0072 ~~~~~~~~~~~~~~
0073 
0074 只需按照 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst 中
0075 所说的报告你的问题,该文档已经包含了要点。下面几点概述了一下只在回归中重要的
0076 方面:
0077 
0078  * 在检查可加入讨论的现有报告时,别忘了搜索 `Linux回归邮件列表
0079    <https://lore.kernel.org/regressions/>`_ 和 `regzbot网页界面
0080    <https://linux-regtracking.leemhuis.info/regzbot/>`_ 。
0081 
0082  * 在报告主题的开头加上“[REGRESSION]”。
0083 
0084  * 在你的报告中明确最后一个正常工作的内核版本和首个出问题的版本。如若可能,
0085    用二分法尝试找出导致回归的变更,更多细节见下。
0086 
0087  * 记得把报告发到Linux回归邮件列表(regressions@lists.linux.dev)。
0088 
0089    * 如果通过邮件报告回归,请抄送回归列表。
0090 
0091    * 如果你使用某些缺陷追踪器报告回归,请通过邮件转发已提交的报告到回归列表,
0092      并抄送维护者以及出问题的相关子系统的邮件列表。
0093 
0094    如果是稳定版或长期支持版系列(如v5.15.3…v5.15.5)的回归,请记得抄送
0095    `Linux稳定版邮件列表 <https://lore.kernel.org/stable/>`_ (stable@vger.kernel.org)。
0096 
0097   如果你成功地执行了二分,请抄送肇事提交的信息中所有签了“Signed-off-by:”的人。
0098 
0099 在抄送你的报告到列表时,也请记得通知前述的Linux内核回归追踪机器人。只需在邮件
0100 中包含如下片段::
0101 
0102        #regzbot introduced: v5.13..v5.14-rc1
0103 
0104 Regzbot会就将你的邮件视为在某个特定版本区间的回归报告。上例中即linux v5.13仍
0105 然正常,而Linux 5.14-rc1是首个您遇到问题的版本。如果你执行了二分以查找导致回
0106 归的提交,请使用指定肇事提交的id代替::
0107 
0108        #regzbot introduced: 1f2e3d4c5d
0109 
0110 添加这样的“regzbot命令”对你是有好处的,它会确保报告不会被忽略。如果你省略了
0111 它,Linux内核的回归跟踪者会把你的回归告诉regzbot,只要你发送了一个副本到回归
0112 邮件列表。但是回归跟踪者只有一个人,有时不得不休息或甚至偶尔享受可以远离电脑
0113 的时光(听起来很疯狂)。因此,依赖此人手动将回归添加到 `已追踪且尚未解决的
0114 Linux内核回归列表 <https://linux-regtracking.leemhuis.info/regzbot/>`_ 和
0115 regzbot发送的每周回归报告,可能会出现延迟。 这样的延误会导致Linus Torvalds
0116 在决定“继续开发还是发布新版本?”时忽略严重的回归。
0117 
0118 真的修复了所有的回归吗?
0119 ~~~~~~~~~~~~~~~~~~~~~~~~
0120 
0121 几乎所有都是,只要引起问题的变更(肇事提交)被可靠定位。也有些回归可以不用这
0122 样,但通常是必须的。
0123 
0124 谁需要找出回归的根本原因?
0125 ~~~~~~~~~~~~~~~~~~~~~~~~~~
0126 
0127 受影响代码区域的开发者应该自行尝试定位问题所在。但仅靠他们的努力往往是不可
0128 能做到的,很多问题只发生在开发者的无法接触的其他特定外部环境中——例如特定的
0129 硬件平台、固件、Linux发行版、系统的配置或应用程序。这就是为什么最终往往是报
0130 告者定位肇事提交;有时用户甚至需要再运行额外测试以查明确切的根本原因。开发
0131 者应该提供建议和可能的帮助,以使普通用户更容易完成该流程。
0132 
0133 如何找到罪魁祸首?
0134 ~~~~~~~~~~~~~~~~~~
0135 
0136 如 Documentation/translations/zh_CN/admin-guide/reporting-issues.rst (简要)
0137 和 Documentation/translations/zh_CN/admin-guide/bug-bisect.rst (详细)中所
0138 述,执行二分。听起来工作量很大,但大部分情况下很快就能找到罪魁祸首。如果这很
0139 困难或可靠地重现问题很耗时,请考虑与其他受影响的用户合作,一起缩小搜索范围。
0140 
0141 当出现回归时我可以向谁寻求建议?
0142 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0143 
0144 发送邮件到回归邮件列表(regressions@lists.linux.dev)同时抄送Linux内核的回归
0145 跟踪者(regressions@leemhuis.info);如果问题需要保密处理,可以省略列表。
0146 
0147 
0148 关于回归的更多细节
0149 ------------------
0150 
0151 
0152 “无回归规则”的目标是什么?
0153 ~~~~~~~~~~~~~~~~~~~~~~~~~~
0154 
0155 用户应该放心升级内核版本,而不必担心有程序可能崩溃。这符合内核开发者的利益,
0156 可以使更新有吸引力:他们不希望用户停留在停止维护或超过一年半的稳定/长期Linux
0157 版本系列上。这也符合所有人的利益,因为 `那些系列可能含有已知的缺陷、安全问题
0158 或其他后续版本已经修复的问题
0159 <http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_ 。
0160 此外,内核开发者希望使用户测试最新的预发行版或常规发行版变得简单而有吸引力。
0161 这同样符合所有人的利益,如果新版本出来后很快就有相关报告,会使追踪和修复问题
0162 更容易。
0163 
0164 实际中“无回归”规则真的可行吗?
0165 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0166 
0167 这不是句玩笑话,请见Linux创建者和主要开发人员Linus Torvalds在邮件列表中的许
0168 多发言,其中一些在 Documentation/process/handling-regressions.rst 中被引用。
0169 
0170 此规则的例外情况极为罕见;之前当开发者认为某个特定的情况有必要援引例外时,
0171 基本都被证明错了。
0172 
0173 谁来确保“无回归”被落实?
0174 ~~~~~~~~~~~~~~~~~~~~~~~~
0175 
0176 照看和支撑树的子系统维护者应该关心这一点——例如,Linus Torvalds之于主线,
0177 Greg Kroah-Hartman等人之于各种稳定/长期系列。
0178 
0179 他们都得到了别人的帮助,以确保回归报告不会被遗漏。其中之一是Thorsten
0180 Leemhuis,他目前担任Linux内核的“回归跟踪者”;为了做好这项工作,他使用了
0181 regzbot——Linux内核回归跟踪机器人。所以这就是为什么要抄送或转发你的报告到
0182 回归邮件列表来通知这些人,已经最好在你的邮件中包含“regzbot命令”来立即追踪它。
0183 
0184 回归通常多久能修复?
0185 ~~~~~~~~~~~~~~~~~~~~
0186 
0187 开发者应该尽快修复任何被报告的回归,以提供及时为受影响的用户提供解决方案,并
0188 防止更多用户遇到问题;然而,开发人员需要花足够的时间和注意力确保回归修复不会
0189 造成额外的损害。
0190 
0191 因此,答案取决于各种因素,如回归的影响、存在时长或出现于哪个Linux版本系列。
0192 但最终,大多数的回归应该在两周内修复。
0193 
0194 当问题可以通过升级某些软件解决时,是回归吗?
0195 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0196 
0197 基本都是。如果开发人员告诉您其他情况,请咨询上述回归跟踪者。
0198 
0199 当新内核变慢或能耗增加,是回归吗?
0200 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0201 
0202 是的,但有一些差别。在微型基准测试中变慢5%不太可能被视为回归,除非它也会对
0203 广泛基准测试的结果产生超过1%的影响。如果有疑问,请寻求建议。
0204 
0205 当更新Linux时外部内核模块崩溃了,是回归吗?
0206 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0207 
0208 不,因为“无回归”规则仅限于Linux内核提供给用户空间的接口和服务。因此,它不包括
0209 构建或运行外部开发的内核模块,因为它们在内核空间中运行与挂进内核使用的内部接
0210 口偶尔会变化。
0211 
0212 如何处理安全修复引起的回归?
0213 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0214 
0215 在极为罕见的情况下,安全问题无法在不引起回归的情况下修复;这些修复都被放弃了,
0216 因为它们终究会引起问题。幸运的是这种两难境地基本都可以避免,受影响区域的主要
0217 开发者以及Linus Torvalds本人通常都会努力在不引入回归的情况下解决安全问题。
0218 
0219 如果你仍然面临此种情况,请查看邮件列表档案是否有人尽力避免过回归。如果没有,
0220 请报告它;如有疑问,请如上所述寻求建议。
0221 
0222 当修复回归时不可避免会引入另一个,如何处理?
0223 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0224 
0225 很遗憾这种事确实会出现,但幸运的是并不经常出现;如果发生了,受影响代码区的资
0226 深开发者应当调查该问题以找到避免回归的解决方法,至少避免它们的影响。如果你遇
0227 到这样的情况,如上所述:检查之前的讨论是否有人已经尽了最大努力,如有疑问请寻
0228 求建议。
0229 
0230 小提示:如果人们在每个开发周期中定期给出主线预发布(即v5.15-rc1或-rc3)以供
0231 测试,则可以避免这种情况。为了更好地解释,可以设想一个在Linux v5.14和v5.15-rc1
0232 之间集成的更改,该更改导致了回归,但同时是应用于5.15-rc1的其他改进的强依赖。
0233 如果有人在5.15发布之前就发现并报告了这个问题,那么所有更改都可以直接撤销,从
0234 而解决回归问题。而就在几天或几周后,此解决方案变成了不可能,因为一些软件可能
0235 已经开始依赖于后续更改之一:撤销所有更改将导致上述用户软件出现回归,这是不可
0236 接受的。
0237 
0238 若我所依赖的功能在数月前被移除了,是回归吗?
0239 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0240 
0241 是的,但如前节所述,通常很难修复此类回归。因此需要逐案处理。这也是定期测试主
0242 线预发布对所有人有好处的另一个原因。
0243 
0244 如果我似乎是唯一受影响的人,是否仍适用“无回归”规则?
0245 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0246 
0247 适用,但仅限于实际使用:Linux开发人员希望能够自由地取消那些只能在阁楼和博物
0248 馆中找到的硬件的支持。
0249 
0250 请注意,有时为了取得进展,不得不出现回归——后者也是防止Linux停滞不前所必需
0251 的。因此如果回归所影响的用户很少,那么为了他们和其他人更大的利益,还是让事情
0252 过去吧。尤其是存在某种规避回归的简单方法,例如更新一些软件或者使用专门为此目
0253 的创建的内核参数。
0254 
0255 回归规则是否也适用于staging树中的代码?
0256 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0257 
0258 不,参见 `适用于所有staging代码配置选项的帮助文本
0259 <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_ ,
0260 其早已声明::
0261 
0262        请注意:这些驱动正在积极开发中,可能无法正常工作,并可能包含会在不久的
0263        将来发生变化的用户接口。
0264 
0265 虽然staging开发人员通常坚持“无回归”的原则,但有时为了取得进展也会违背它。这就
0266 是为什么当staging树的WiFi驱动被基本推倒重来时,有些用户不得不处理回归(通常可
0267 以忽略)。
0268 
0269 为什么较新版本必须“使用相似配置编译”?
0270 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0271 
0272 因为Linux内核开发人员有时会集成已知的会导致回归的变更,但使它们成为可选的,并
0273 在内核的默认配置下禁用它们。这一技巧允许进步,否则“无回归”规则将导致停滞。
0274 
0275 例如,试想一个新的可以阻止恶意软件滥用某个内核的接口的安全特性,同时又需要满足
0276 另一个很罕见的应用程序。上述的方法可使两方都满意:使用这些应用程序的人可以关闭
0277 新的安全功能,而其他不会遇到麻烦的人可以启用它。
0278 
0279 如何创建与旧内核相似的配置?
0280 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0281 
0282 用一个已知良好的内核启动机器,并用 ``make olddefconfig`` 配置新版的Linux。这
0283 会让内核的构建脚本从正在运行的内核中摘录配置文件(“.config”文件),作为即将编
0284 译的新版本的基础配置;同时将所有新的配置选项设为默认值,以禁用可能导致回归的
0285 新功能。
0286 
0287 如何报告在预编译的普通内核中发现的回归?
0288 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0289 
0290 您需要确保新的内核是用与旧版相似的配置编译(见上文),因为那些构建它们的人可
0291 能启用了一些已知的与新内核不兼容的特性。如有疑问,请向内核的提供者报告问题并
0292 寻求建议。
0293 
0294 
0295 用“regzbot”追踪回归的更多信息
0296 -----------------------------
0297 
0298 什么是回归追踪?为啥我需要关心它?
0299 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0300 
0301 像“无回归”这样的规则需要有人来确保它们被遵守,否则会被有意/无意打破。历史证
0302 明了这一点对于Linux内核开发也适用。这就是为什么Linux内核的回归跟踪者Thorsten
0303 Leemhuis,,和另一些人尽力关注所有的回归直到他们解决。他们从未为此获得报酬,
0304 因此这项工作是在尽最大努力的基础上完成的。
0305 
0306 为什么/如何使用机器人追踪Linux内核回归?
0307 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0308 
0309 由于Linux内核开发过程的分布式和松散结构,完全手动跟踪回归已经被证明是相当困难
0310 的。因此Linux内核的回归跟踪者开发了regzbot来促进这项工作,其长期目标是尽可能为
0311 所有相关人员自动化回归跟踪。
0312 
0313 Regzbot通过监视跟踪的回归报告的回复来工作。此外,它还查找用“Link:”标签引用这
0314 些报告的补丁;对这些补丁的回复也会被跟踪。结合这些数据,可以很好地了解当前修
0315 复过程的状态。
0316 
0317 如何查看regzbot当前追踪的回归?
0318 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0319 
0320 参见 `regzbot在线 <https://linux-regtracking.leemhuis.info/regzbot/>`_ 。
0321 
0322 何种问题可以由regzbot追踪?
0323 ~~~~~~~~~~~~~~~~~~~~~~~~~~~
0324 
0325 该机器人只为了跟踪回归,因此请不要让regzbot涉及常规问题。但是对于Linux内核的
0326 回归跟踪者来说,让regzbot跟踪严重问题也可以,如有关挂起、损坏数据或内部错误
0327 (Panic、Oops、BUG()、warning…)的报告。
0328 
0329 如何修改被追踪回归的相关信息?
0330 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
0331 
0332 在直接或间接回复报告邮件时使用“regzbot命令”即可。最简单的方法是:在“已发送”文
0333 件夹或邮件列表存档中找到报告,然后使用邮件客户端的“全部回复”功能对其进行回复。
0334 在该邮件中的独立段落中可使用以下命令之一(即使用空行将这些命令中的一个或多个与
0335 其余邮件文本分隔开)。
0336 
0337  * 更新回归引入起点,例如在执行二分之后::
0338 
0339        #regzbot introduced: 1f2e3d4c5d
0340 
0341  * 设置或更新标题::
0342 
0343        #regzbot title: foo
0344 
0345  * 监视讨论或bugzilla.kernel.org上有关讨论或修复的工单::
0346 
0347        #regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/
0348        #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
0349 
0350  * 标记一个有更多相关细节的地方,例如有关但主题不同的邮件列表帖子或缺陷追踪器中的工单::
0351 
0352        #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789
0353 
0354  * 标记回归已失效::
0355 
0356        #regzbot invalid: wasn't a regression, problem has always existed
0357 
0358 Regzbot还支持其他一些主要由开发人员或回归追踪人员使用的命令。命令的更多细节请
0359 参考 `入门指南 <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_
0360 和 `参考手册 <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_ 。
0361 
0362 ..
0363    正文结束
0364 ..
0365    如本文件开头所述,本文以GPL-2.0+或CC-BY-4.0许可发行。如您想仅在CC-BY-4.0许
0366    可下重分发本文,请用“Linux内核开发者”作为作者,并用如下链接作为来源:
0367    https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/translations/zh_CN/admin-guide/reporting-regressions.rst
0368 ..
0369    注意:本RST文件内容只有在来自Linux内核源代码时是使用CC-BY-4.0许可的,因为经
0370    过处理的版本(如经内核的构建系统)可能包含来自使用更严格许可证的文件的内容。