我的第一个Linux内核贡献，被剥夺了！

撰稿 | 言征

Ariel Miculas，是一位开源贡献者，目前在思科任职软件工程师，最近他在自己的博客上开喷Linux内核：“为什么我贡献了问题和补丁代码，最后贡献者的名单里却没有我？”

自封的Linux内核“贡献者”

翻开Ariel的博客，他这样介绍自己：“我是一位充满激情的软件工程师，拥有网络安全硕士学位。我感兴趣的领域是系统编程，包括管理程序、操作系统，以及最近的Linux文件系统。我也是一个开源贡献者，以下是我贡献的一些项目：Linux内核、capnproto-rust、squashfuse。”

可以看出，Ariel认为自己是对Linux内核有贡献的。然而让他气愤地是，他的第一个内核贡献却被内核维护者被无情剥夺了。

复现了六年前的Linux内核Bug，一直无解 GDB是Linux下的调试利器，而gdbserver是配合gdb实现远程调试的工具。大约在一年半前，Ariel致力于解决掉一个有关gdbserver远程项目调试的问题：gdbserver 无法调试在 PowerPC32 架构上运行的多线程应用程序。与 gdbserver 的连接已断开，并且无法再控制调试会话。 庆幸的是，很多人已经调查过这个问题，Ariel团队仍然不确定问题出在哪个软件组件上：它可能是工具链、gdbserver、Linux 内核或他们应用的自定义补丁内核树的顶层。一时间难以找到根本原因。

Ariel结合现有分析和谷歌搜索，对这个问题进行了深入研究，终于取得了第一个突破：他找到了一个与其描述问题症状相同的电子邮件线程，而且还指出了引入它的一个关于Linux内核的确切提交（kernel/git/torvalds/linux.git）。

引入该错误的补丁将thread_struct thread的定义从task_struct的中间移动到了末尾，这个更改看起来貌似无害，但会带来一些低级问题——

我看到的是 gdbserver 为每个线程发送 SIGSTOP 到内核并等待响应。内核确实接收到所有信号，但仅在错误情况下响应其中的一些信号。

然后，它与我的“ps”输出相匹配，因为我看到某些线程未处于 pthread_stop 状态，然后 gdbserver 被挂起。

问题在于，在与 gdbserver 交互后，某些线程处于错误的进程状态，并且 gdbserver 无法再控制它们。

古老的问题往往源于简单的错误

Ariel 花了 3-4 天阅读 PowerPC 架构相关的提交描述以及task_struct的版本变化，却发现这个问题并没有在后续的内核版本得到解决。

确定问题何时复现之后，Arielkaishi使用一款工具来检查 task_struct的布局，同时用 ftrace来确定调试进程的线程何时被调度，最后终于找到了原因：可能是内存损坏的问题：与其他线程不同，卡住的线程仅被调度一次。然而，一开始其实他就否认了这个问题，因为在Linux邮件列表里有关原始线程的描述：

缓冲区的内容始终为零并且不会改变。所以至少没有人向缓冲区写入非零值。

后来，Ariel研究了如何在 Linux 上使用硬件断点，最终基于某个 stackoverflow 的答案实现了一个新的 Linux 内核模块，该模块可以在__state 字段上放置一个硬件断点 ，以找出到底是谁写入它。

https://elixir.bootlin.com/linux/v6.5.5/source/include/linux/sched.h#L746

Ariel兴奋地总结了找到这个Bug的方法：通过自定义内核模块显示了写入__state字段的位置的堆栈跟踪。task_struct一个异常值揭示了 ptrace_put_fpr中的缓冲区溢出。

这导致重要字段被 task_struct覆盖，例如__state存储进程状态的字段，内核还使用它来跟踪调试器停止了哪些进程等等。

溢出的原因也很简单：内核需要对 64 位元素数组进行索引，但 fp_state.fpr 数组中只有 32 个。

向上游发送补丁，却被维护者摆了一道

发现解决问题的过程非常极客，但发送补丁开始之后，却让Ariel感觉不爽了。

Ariel后来向 Linux 内核安全团队 (security@kernel.org) 提交了第一个补丁，不幸的是，由于这个邮件列表是私人的，所以无法链接到原始补丁。

后来PowerPC 维护者Michael Ellerman跟进并告知，他将私下联系来解决这个问题。实际上，Ariel已经向他发送了两个修复该问题的补丁：发送到安全邮件列表的原始补丁和另一个版本 （与第一个完全不同），第二个版本解决了在回复最初提交的内容时收到的一些建议。

Michael Ellerman 还是没有接受这些建议，而是实施了他自己的修复版本。Ariel有些沮丧，表示：希望能接受自己的补丁，这样就可以获得修复此问题的荣誉并成为内核贡献者。同时也愿意与维护者合作，解决他的反馈并发送补丁的后续版本。

然而维护者的答复却让Ariel感到非常困惑和侮辱：

抱歉，我想以不同的方式修复它。如果您想成为 Linux 内核贡献者，这里有一个您可以解决的问题。

“他不想因为解决问题而获得认可，而是想让我做更多的工作。我和我的公司应该因解决这个问题而获得应有的荣誉，特别是考虑到我们为此付出了多少努力。”

侮辱性极强：

贡献了补丁，却只被授予了“报告者”的头衔

Ariel认为只获得“报告者”标签非常不公平。因为“报告者”报签的分量远不及贡献者标签——它是向那些发现错误并报告错误的人表示感谢，并希望能够激励他们将来再次帮助我们。

事后，Ariel对内核社区的印象急转直下。相反，他因自己的工作没有得到适当的认可而感到被贬低和愤怒。

“我花了很多时间和精力进行根本原因分析，修复错误，测试和验证修复，从公司其他工程师那里获取反馈，使修复适应最新的内核版本，并向 PowerPC 维护者 Michael Ellerman 发送两个不同的补丁。他没有接受我的补丁或指导我找到更好的解决方案，而是继续实施自己的修复方案，只对我报告问题给予认可（而且这个问题还是六年前已经报告过）。”

Linux内核维护，对于“贡献者”有些吝啬

此事争议的一个焦点在于，如果维护者已经阅读了Areil的补丁，之后改变了一些风格，并自己提交这个补丁，那么就会存在借用补丁提交者的事实。

又或者即便提交者的代码很糟糕，但也不应该很不屑的回复一句：我想用不同的方式修复它。毕竟，如果没有没有原始代码，我们连重构修复的机会都没有。

诚然，出于质量目的，维护者可以坚持自己的引进内核的代码，但很显然，Ariel是该补丁的共同贡献者，而不仅仅是Bug的“报告者”。

通过Reddit上用户的评论也能看出，Linux内核维护者对于提交补丁代码者的认可力度不足已经不是个例：

“前几次我向 Linux 内核提交建议补丁（在通过 LKML 半自动提交成为可能之前），我与维护者（本例中为 Ted Tso）进行了对话。一旦他对我的工作的正确性感到满意，他就合并了补丁，一切都很好。我从未要求过，也没有得到过任何荣誉。”

希望这样的情况能够得到改善，否则会让一些开源贡献者们失去对“开源”的热爱。

参考链接：

https://ariel-miculas.github.io/How-I-got-robbed-of-my-first-kernel-contribution/