LWN：利用机器学习来找出有bug的patch！

点击上方蓝色“Linux News搬运工”关注我们~

Identifying buggy patches with machine learning

By Jonathan Corbet
November 4, 2019

---

OSS EU

原文来自：https://lwn.net/Articles/803695/

stable kernel的使命就是希望能包含尽量多的重要bug fix，为了达到这个目的，stable kernel maintainer开始尝试利用机器学习来确认哪些patch应该被放进stable tree里去。这个方案一定意义上成功了，不过在2019 Open Source Summit Europe上，Sasha Levin提出一个问题，是否能更进一步改善这个过程。是否能用机器学习系统来确定是哪些patch导致了bug，截获他们，从而能避免系统出错。

Levin说，任何一个bug fix patch，都应该包含一个tag来指明它应该被包含到stable分支上。不过如果仅仅依赖这个tag的话，就会漏掉很多重要的fix。mainline patch大概有3~4%的做过这个标记，不过实际上应该放到stable分支上的patch其实应该占20%左右。要求所有开发者都记着打上tag的方法还是不太有效，他就自己开发了一个机器学习系统来自动找出mainline上众多patch中属于bug fix类型的，排入人工review的队列。

这个系统会用不少启发式条件，如果changelog里面包含“fix”或者“cause a panic”等语句的话，很可能就是一个重要的fix。还有很短的patch也可能是fix。另外一个指标是新加入了类似下面这样的代码：

    if (x == NULL)
        return -ESOMETHING;

最终，确实能够自动找出不少的bug fix patch。不过既然这种方式可行，那么是不是能利用一个类似的系统来找出bug？这个问题其实更加困难一些。Levin抱怨说没有人在自己patch的changelog里面指明“this commit has a bug”或者"this will crash your server"，这其实是Andrew Morton多年来一直向他强调的一点。仅仅查看代码结构的话只能找出一些特别简单的bug，其实现在已经有一些静态分析的系统实现了这些做法。他得找一些其他方向。

其他方向，就只剩下review和测试了。分析这个patch得到的review意见，可以得出很多有用信息。review过程中是不是有很多细节讨论？是不是能看出这个review者是否真的实验过这个代码？review中除了排版格式问题之外是否讨论过其他问题？还可以采用情感分析（sentiment analysis）来了解一下review者对这个patch的整体的感受。

并不是所有review者都是平等的，因此这个系统需要能对每一位review者都做一些评定。随着时间增长，它就能够断定是否某位开发者review过的patch会可能有bug。还有review者的角色也是个有效信息，如果是相关子系统的maintainer或者一位长期频繁贡献者，那么他们的意见就应该得到更多重视。

这个系统应该能查询到某个patch在linux-next里面已经存在多长时间了，经过了多少轮，针对它的讨论的质量如何。自动测试系统的输出应该也要考虑进来，不过只能作为参考。KernelCI对ARM patch的测试还是更加可靠一些，而0day系统更擅长对x86 patch的测试一些。人工测试的结果应该对patch质量更加有价值。假如某个patch提到说它已经经过了某个数据中心几千台机器的测试，那么基本上也就不会有bug了。

还有，也可以顺便查看一下代码质量，不过这个很难评价。可以看一下这个patch的第一版存在了多少问题，这个可能有点价值。不过Levin也不确定这个方向能做多少工作。

等这些有价值的数据都获取之后，就需要建立一个训练集。其中可能包含大量的patch，当然也要有个办法来标记每个patch是否包含bug。有很多patch里提供的Fixes tag就有助于提供相关信息了，不过这个系统并不会对所有的bug都感兴趣，例如拼写错误或者理论上的竞争关系（theoretical race）就不用关心了。最终，他采用了一个简单的方法，直接针对那些后来被revert掉的patch和那些有个Fixes tag指向它的patch来做训练。

这里就刚好得出了一些有意思的信息，例如这些bug是从哪里以及何时引入进来的。他本来以为这些bug基本上都是在merge window期间引入的，然后在后面的-rc发布周期中解决掉的，不过数据说明这个看法不对。按照代码行数统计的话，比起merge-window期间的patch，在后期的-rc发布周期中合入的patch出现bug的概率要高出2倍。

在merge window中合入的patch，看起来都是经过较好测试的。而在后来加入的patch，通常是希望解决某些问题的，经过的测试会少很多，甚至干脆没有测试。Levin也说我们不应该这么操作，不应该在开发周期的末期来急着塞bug fix进去。反正大家在生产系统里面都不会直接用mainline kernel，所以还不如对这些patch进行更多测试，等准备就绪之后再放进stable分支上发布出去。开发者应该对stable版本抱有更多信任，减少在rc周期后期乱塞进去的东西。

Levin还就这些数据对Linus Torvalds抱怨过。Torvalds基本赞成这些解读，不过他认为这个流程设计出来就是会这样的。每个开发周期后期的问题通常都会更加复杂，因此相应的fix也会更加复杂，从而更大概率产生新的bug。Levin赞同这一点，不过不同意他的结论。他认为社区里还是需要对发布周期末期的patch更加严格要求。

回到我们在讲的机器学习系统，他介绍说，目前自己已经在用这个系统来标记那些需要经过仔细人为审查的patch了，也确实帮助他在原本计划合入stable分支的patch中找到了一些bug。这个系统也部分地用来对将要合入stable分支的patch做一些评估。不过，原本计划能实现一个通用的监测含有bug的patch的目的，看起来还很遥远。

Levin总结了一些能改善kernel开发流程的想法。首先需要改进这个发布周期后期的质量问题，既然大家都已经知道这里有问题了。还有需要改善对kernel patch在不同开发板上的测试，目前我们的测试能力还是太有限了。需要让更多的测试在真实硬件上执行，这样才会更有参考价值。他也希望能针对哪些patch可以被接受合入，建立一个标准策略，例如需要在linux-next存在多长时间，需要拿到哪些signoff和review，诸如此类的。这些策略目前在不同的子系统之间差异很大，有些maintainer就不太在乎这些，这个不太好，需要改进。

[Thanks to the Linux Foundation, LWN's travel sponsor, for supporting your editor's travel to the event.]

全文完

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

极度欢迎将文章分享到朋友圈 
热烈欢迎转载以及基于现有协议修改再创作～

长按下面二维码关注：Linux News搬运工，希望每周的深度文章以及开源社区的各种新近言论，能够让大家满意～