Linus 用 Claude Code 改 Linux 内核，大神也没兜住代码里的 Bug

Linus Torvalds 使用 Claude Code 编写 Linux 页面缓存修复补丁，在一项基准测试中将读取吞吐量提升了 23 倍。不过，补丁尚未合入，人类内核审查者就凭借专业直觉，揪出了连 AI 和大神都没能发现的 bug。这再次证明，人类代码审查依然是不可或缺的最终防线。

Linux 的创造者、长期担任首席维护者的 Linus Torvalds 借助 Anthropic 的 Claude Code，着手解决一个困扰开发者两年多的内核性能问题。

周二，他提交了一组包含 10 个补丁的系列。在 Ryzen Threadripper 上运行的合成基准测试中，这组补丁将读取吞吐量提升了 23 倍。

Torvalds 曾花 18 个月运行自己编写的一版有缺陷的修复代码，试图解决页面缓存中的引用计数瓶颈；其他开发者提出的方案也遇到了问题。新补丁从常见的缓冲读取路径中移除了 folio 引用计数操作。不过，Torvalds 提醒说，在真实工作负载中，性能提升会小得多。

在后续审查中，维护者发现补丁存在一个竞争条件。

Kiryl Shutsemau 指出，在 filemap_read_rcu_batch() 中，如果 folio 被替换后文件大小（i_size）又随之扩展，读取路径就可能把文件中尚未写入的数据返回给用户程序。审查者也对补丁的内存回收机制提出质疑。Torvalds 已将后续开发工作交给 Shutsemau；他此前也研究过这个瓶颈。

用更通俗的话说，读取文件时，内核负责保存这段数据的内存页刚好被换掉，文件大小又紧接着扩展。两件事交错发生后，读取代码可能把文件中新扩出的、实际还没写入内容的部分，当成有效数据交给应用程序。只有这些操作恰好按这个顺序撞在一起时，问题才会出现。

这种由于多线程并发时序不当而导致程序可能产生错误行为的竞争条件，本身就是一种经典的软件 bug。

据 Hardware Busters 报道，在 Torvalds 的 Core i7-8565U 笔记本电脑上进行的 8 线程测试中，跨核加载 HITM 事件里有 99.92% 与 folio 引用计数争用有关。这个瓶颈于 2024 年由 Oracle 工程师 Matthew Wilcox 提出。他长期参与 Linux 内核内存管理开发；问题是在一个客户的工作负载中暴露出来的。

Claude Code 编写补丁

此前，Linux 创始人 Linus Torvalds 曾公开痛批过那些夸大 AI 作用的言论。他当时直言：“每当我看到有人吹嘘‘我们 99% 的代码都是 AI 写的’，我真的会生气。因为我敢打包票，这帮人的代码 100% 都是靠编译器生成的，但他们却从来不这么说。”

然而有趣的是，这位对 AI 泡沫保持高度清醒的开源教主，最近自己也开始动手做实验了。

周日，Phoronix 的 Michael Larabel 发现 Torvalds 的代码树中出现了一个名为 noref-filemap-read-with-llm 的实验分支。要知道，Torvalds 的代码树里极少保留主开发分支（Mainline）以外的内容。

这组基于 Linux 7.3-rc6 的补丁一共包含 8 个提交（Commits），并在提交记录中坦白、清晰地标注了 Anthropic 旗下的开发者工具 Claude Code 参与的具体工作。

根据 Torvalds 的说法，这组补丁的代码、测试程序，甚至提交前的初步审查工作，都是 Claude Code 在他的指导下完成的。性能测量则由他在自己的机器上进行。

也就是说，尽管这组补丁在提交前通过了 AI 的自查与审查，但其中隐藏的竞争条件 Bug，最终依然是在合入主分支前，被社区里的人类维护者给揪了出来。

这组补丁解决的是一个棘手的内核并发问题。

此前的优化方案试图在“不持有 folio 引用”的情况下直接复制数据，并在复制完成后再检查数据的有效性。但这种做法留下了隐患，极易在内存回收和替换操作时触发竞争条件（Race Condition）。

为了彻底解决这个漏洞，后续演进的 rcu-free-v3 系列（共包含 10 个补丁）引入了全新的 PG_rcu_free 标志和 RCU 延迟回收机制。只要数据复制过程中没有触发缺页异常，该机制就能在数据向用户空间复制期间，为 folio 提供极其安全的保护。

在 Claude Code 的协助下，这组补丁展现出了令人惊叹的性能优化幅度。

• 在 Linus 的笔记本上（8 线程测试）： 最初的 8 个补丁几乎让吞吐量飙升至原来的 3 倍（从每秒 1000 万次读取提高到最高 3300 万次），每次读取消耗的内核周期也从约 2950 降至 725。

• 在 64 线程 Threadripper 上（严重争用测试）： 吞吐量从每秒 1330 万次读取跃升至 3.04 亿次，每次读取消耗的 CPU 周期更是从近 2 万骤降至 735。

然而，如此激进的性能提升并非没有代价。

第一版实现中的延迟回收机制，会在某个 CPU 排队等待的页面超过 1024 个时强制触发一次加速宽限期。Hardware Busters 对此作了报道。向尚未映射的用户页面读取数据时，也会额外触发一次缺页异常，然后才回退到现有路径。这使得单线程读取 16 字节数据的开销从约 4150 个周期升至 6550 个周期。目前还不清楚这一性能退化是否会在 rcu-free-v3 中继续存在。

大佬过招：内存回收设计的交锋

Wilcox 对新的 PG_rcu_free 标志提出质疑，建议改用页面类型，并在 RCU 宽限期过后回收不活跃链表中的 folio。

Torvalds 否决了这两种方案。他认为，必须趁 folio 仍可映射到用户空间时设置该标志；而只从不活跃链表回收 folio，则无法覆盖 truncate 和打洞操作。随后，Shutsemau 建议将该标志限制在 64 位系统上。Arm 工程师、Linux 内存管理维护者 David Hildenbrand 支持这一方案。

而在关键函数 filemap_read_rcu_batch() 中，Shutsemau 进一步拆解了他发现的那个竞争条件（Race Condition）隐患：

在无引用的 RCU 读取路径中，原补丁的逻辑是先获取当前的 folio，然后再去读取文件的大小（i_size）。

Shutsemau 指出，这里存在一个致命的时间差：当一个旧的 folio 被驱逐并替换为一个全新的 folio 后，如果另一个进程恰好在此时扩展了文件大小（i_size）。此时，读取路径依然在使用已经被替换掉的旧 folio 的快照信息，但在计算读取边界时，却采用了新扩展出来的 i_size。这就导致读取代码会错误地“越界”读到该文件新扩展出的、实际在磁盘和内存中都尚未写入有效数据的空白区域，直接将“尚未写入的数据”返回给了用户程序。

为了消除这一时序隐患，Torvalds 提出了明确的重构方向：必须改变执行顺序，将文件大小（i_size）的读取操作提前，并在随后将 folio 的有效性检查与边界逻辑进行合并合并。Shutsemau 随后完全采纳了这一改进思路，并将这一逻辑顺利纳入了修订版补丁中。

参考链接：