LWN：对syzbot report分类过程中的问题！

关注了就能看到更多这么棒的文章哦～

Troubles with triaging syzbot reports

By Jake Edge
December 14, 2022
DeepL assisted translation
https://lwn.net/Articles/917762/

来自 syzbot 这个内核模糊测试机器人（kernel fuzz-testing robot）的报告，通常并不会在邮件列表中引发带有严重对立的讨论，但最近就发生了这么一回。虽然争吵谩骂是很让人遗憾的，但背后的问题是重要的。这场争论是围绕着如何能最好地给受影响的子系统报告 bug，以及最终如何不浪费维护者的时间。

Al Viro 显然对 ntfs3 文件系统的 syzbot 报告不 CC 给 ntfs3 的维护者的做法感到很厌烦了。syzbot 把邮件发送到了内核邮件列表，但 Viro 在回复中用大写字幕形式强调说："任何在复现者手中的涉及 NTFS3 的 BUG 报告都要抄送给 NTFS3 的维护者"。他表示，这个抱怨在过去已经被转达了许多次，但问题没有得到解决，所以他打算停止查看这些 bug 报告。也就是会 "直接转发到/dev/null 去"。

在 Hillf Danton 的一个一言难尽的答复之后，Viro 回复了他所看到的问题的更多细节。他提到了 9 月份的一个邮件，在那里他提出了一个类似的要求，并说其他人也向 syzbot 的维护者报告了这类问题。问题在于，syzbot 发送的邮件没有包含足够的有用信息，让人无法快速判断是否与自己关注的领域有关：

这其实是一个分流（triage）的问题；现在的情况是，syzkaller 的人希望来自机器人的任何邮件都会被 fsdevel 的每个人看一遍，就当是和他们有关。更重要的是，这不仅仅是 "阅读一下邮件" 而已。在当前这种情况下，邮件正文中的信息几乎都是没有什么用的。[…]

真正让我生气的是，在发送方这边，只需要做一个微不足道的检查就好，如果你要对一个文件系统进行模糊测试，就在报告中写上说明，最好是在主题中就写清楚。当然，这是你的代码，你可以决定把你的时间花在什么地方（你==syzkaller 维护者）。但是请记住，对于 [收件人] 来说，这是一个大量的重复性工作，对于那些最终受到打扰的大多数人来说这些劳动都是毫无价值的。每次他们收到来自该来源的邮件都是这样。

很多次忽略掉礼貌性建议之后，就会获得不礼貌的建议，以及采用 .procmailrc 来处理的下场，就是这么简单…

Danton 误解了 Viro 的抱怨，但 Matthew Wilcox 试图给出解释。所抱怨的不是 linux-fsdevel 列表被放到了邮件抄送列表上，而是 ntfs3 的维护者没有被抄送到。Wilcox 说："所以这就变成了只是纯粹的噪音。而噪声太多就意味着信号受到损失"。

Viro 表示同意，并不厌其烦地描述了他（以及任何其他对 syzbot 报告感兴趣的接收者）将如何对其进行分流，最终在 syzkaller dashboard 上为该 bug 和其 syzkaller reproducer 生成相应的条目。正如 Viro 所指出的，这个最终处理生成的条目中，就像是对 "线路噪音（line noise）" 进行了噪声抑制，确实能够给出足够的信息，可以看出被模糊处理的是一个 ntfs3 文件系统。但这些信息并没有出现在电子邮件中（或者，最好是电子邮件的主题上），也没有被利用来把报告传达给正确的人看。这里根本问题是，syzkaller/syzbot 的维护者没有提供相关的数据，而这些数据应该很容易得到：

从我在各种讨论中看到的情况来看，syzkaller 的人的假设似乎是大部分相关信息都在 stack trace 里，只要提供这个就足以满足实际需要了，所有超出这个范围的东西都被视为没有必要的特殊情况。[…]

这里需要打破了它的基本假设，也就是对于许多 bug 报告来说，stack trace 并不包含相关的信息。进行分析就需要得到更多的补充数据，而这些数据对机器人来说应该是非常容易得到的。当然，这是你的代码，你有权决定自己的优先级，但 bug 报告只会在不被忽视的情况下才有用，训练人们忽视这些报告是一个坏主意……

Ted Ts'o 表示同意，并指出他几年来一直要求进行这种改进。Syzbot "没有做那些真正可以自动完成的事情——而云端虚拟机的时间很便宜但是上游维护者的时间很昂贵"。他说，实际上，Syzbot 的开发者并没有尊重上游维护者的时间。它的很多方面都在一直得到改善，但确实在这个特定领域里还没有改进过：

现在，对 Syzbot 团队给出公平的评价，确实他们让 Syzbot 控制台变得更好了。你现在可以下载 Syzbot trace，也可以下载一个 mounted file system，而在以前，你必须做很多工作才能从 C reproducer 中提取出文件系统（它是作为压缩数据存储在独立的固定长度的 C 数组中的）。所以，事情确实是在有好转的。

Marco Elver 报告说，这个问题正在由 syzbot 项目来进行调查。他指出了 syzkaller（和 syzbot）的创建者 Dmitry Vyukov 在 11 月底发布的一个 bug report 上的评论。它提到了 Viro 抱怨这个问题的另一封邮件。进一步阅读这个 bug 的讨论的话，可以清楚地看到，在确定搜索内容以及在邮件主题行添加标签从而确定哪个文件系统正在被模糊测试这些方面都正在取得进展。

该线程最终完全走火入魔了，甚至包括一条似乎很可能会引起内核行为准则委员会（kernel code of conduct committee）的回应的邮件。该主题的整体氛围是不太好的，至少在某些地方是如此，但 Ts'o 和 Viro（尤其是后者）都花了相当多的时间来耐心地重申一路走来提出过很多次的问题，尽管他们的音量较小。这些请求并没有走远，所以，正如 Ts'o 所说，"也许 Al [Viro]的一些更有说服力的做法，会激发他们优先考虑这个功能请求"。

模糊测试产生了大量的报告。为了使测试有效（能够对大家有用），这些报告就必须要引出相应的行动。既然这是大家的目标，那么能创建出可以快速传送给正确的人的报告，显然是很有必要的。这不是我们第一次看到关于模糊测试报告的抱怨，也不是第一次在文件系统背景下讨论到这个，但希望我们能尽快看到改进。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～