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

撰稿 | 言征

Ariel Miculas，一位积极的开源贡献者，目前在思科担任软件工程师，最近在自己的博客上发表了对Linux内核的不满：“为什么我提交了问题和修补代码，却没有出现在贡献者名单中？”

自称Linux内核“贡献者”

浏览Ariel的博客，他这样描述自己：“我是一位热情洋溢的软件工程师，拥有网络安全硕士学位。我的兴趣领域是系统编程，包括虚拟机管理程序、操作系统，以及最近的Linux文件系统。我也是一个开源贡献者，以下是我参与的一些项目：Linux内核、capnproto-rust、squashfuse。”

显然，Ariel认为自己对Linux内核有贡献。然而，他愤怒的是，他的首次内核贡献却被内核维护者无情地剥夺了。六年前的Linux内核Bug重现，GDB是Linux下的调试利器，而gdbserver是用于远程调试的工具。大约在一年半前，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的版本变化，却发现这个问题并没有在后续的内核版本得到解决。

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

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

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

https://www.php.cn/link/eb69ec3b34db9fc42da12bd9c3a8ad37

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

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

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

向上游发送补丁，却被维护者摆了一道，发现解决问题的过程非常极客，但发送补丁开始之后，却让Ariel感到不爽了。

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

超能文献

超能文献是一款革命性的AI驱动医学文献搜索引擎。

14

查看详情

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

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

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

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

侮辱性极强：

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

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

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

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

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

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

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

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

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

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

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

参考链接：

https://www.php.cn/link/f38672a52518ee94f8ad3e749ba5fff5

以上就是我的第一个Linux内核贡献，被剥夺了！的详细内容，更多请关注php中文网其它相关文章！