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

Linus uses ClaudeCode to modify the Linux kernel, even the guru couldn’t catch the bugs in the code

The creator of Linux, long‑time chief maintainer Linus Torvalds, leveraged Anthropic’s Claude Code to tackle a kernel performance issue that has plagued developers for over two years.

On Tuesday, he submitted a series of ten patches. In a synthetic benchmark on a Ryzen Threadripper, this patch set increased read throughput by 23×.

Torvalds spent 18 months running a buggy version of his own fix code, trying to solve the reference‑count bottleneck in the page cache; other developers’ proposals also ran into problems. The new patch removes the folio reference‑count operation from the common buffered read path. However, Torvalds cautioned that under real‑world workloads the performance gain would be much smaller.

In a subsequent review, maintainers discovered a race condition in the patch.

Kiryl Shutsemau pointed out that in filemap_read_rcu_batch(), if a folio is replaced and the file size (i_size) subsequently expands, the read path could return data that has not yet been written to the file to the user program. Reviewers also questioned the patch’s memory reclamation mechanism. Torvalds has handed subsequent development work to Shutsemau; he has previously studied this bottleneck.

In plain terms, when reading a file, the kernel happens to swap out the memory page that holds the data being read just as the file size is immediately extended. After these two events interleave, the read code may treat the newly expanded portion of the file—whose contents haven’t actually been written yet—as valid data and pass it to the application. The problem only appears when these operations occur in that exact order.

This kind of race condition, caused by improper multithreaded concurrency timing that can lead to erroneous program behavior, is a classic software bug.

According to Hardware Busters, in an 8‑thread test on Torvalds’s Core i7‑8565U laptop, 99.92% of cross‑core HITM events were related to folio reference‑count contention. This bottleneck was identified in 2024 by Oracle engineer Matthew Wilcox, who has long been involved in Linux kernel memory‑management development; the issue surfaced in a customer’s workload.

Previously, Linux founder Linus Torvalds publicly criticized those who exaggerated the role of AI. He said at the time, “Whenever I see someone bragging ‘99% of our code is written by AI,’ I really get angry. Because I can guarantee that 100% of those people’s code is generated by the compiler, yet they never say that.”

Interestingly, this open‑source guru who stays highly aware of the AI hype bubble has recently started experimenting himself.

On Sunday, Phoronix’s Michael Larabel discovered an experimental branch called noref-filemap-read-with-llm in Torvalds’s code tree. It’s worth noting that Torvalds’s tree rarely retains anything outside the main development branch (Mainline).

This set of patches based on Linux 7.3‑rc6 consists of eight commits, and the commit messages openly and clearly label the specific work contributed by Anthropic’s developer tool Claude Code.

According to Torvalds, the code, test programs, and even the preliminary review before submission for this patch set were completed by Claude Code under his guidance. Performance measurements were performed by him on his own machine.

In other words, although this patch set passed AI self‑checks and review before submission, the hidden race‑condition bug was ultimately discovered by human maintainers in the community before it was merged into the main branch.

These patches address a tricky kernel concurrency issue.

The previous optimization attempted to copy data directly without holding a folio reference, and then verify the data’s validity after the copy completed. However, this approach left a vulnerability that could easily trigger a race condition during memory reclamation and replacement operations.

To completely fix this vulnerability, the subsequent rcu-free-v3 series (a total of 10 patches) introduced a brand‑new PG_rcu_free flag and an RCU delayed reclamation mechanism. As long as no page‑fault occurs during data copying, this mechanism can provide extremely safe protection for folios while the data is being copied to user space.

With the assistance of Claude Code, this patch set demonstrated astonishing performance improvements.

• On Linus’s laptop (8‑thread test): The initial 8 patches almost tripled the throughput to three times (rising from 10 million reads per second to a peak of 33 million), and the kernel cycles per read dropped from about 2950 to 725.

On a 64‑core Threadripper (severe contention test): throughput jumps from 13.3 million reads per second to 304 million, and the CPU cycles per read drop dramatically from nearly 20 k to 735.

However, such aggressive performance gains do not come without cost.

The delayed reclamation mechanism in the first‑version implementation forces an accelerated grace period when more than 1,024 pages are queued on a CPU. Hardware Busters reported on this. Reading data from a user page that has not yet been mapped also triggers an extra page‑fault before falling back to the existing path. This raises the cost of a single‑threaded 16‑byte read from about 4,150 cycles to 6,550 cycles. It is still unclear whether this performance regression will persist in rcu-free-v3.

Wilcox questions the new PG_rcu_free flag, suggesting to use page types instead and to reclaim folios in the inactive list after the RCU grace period.

Torvalds rejected both proposals. He argued that the flag must be set while the folio can still be mapped into user space; and reclaiming a folio only from the inactive list cannot cover truncate and hole‑punch operations. Afterwards, Shutsemau suggested limiting the flag to 64‑bit systems. ARM engineer and Linux memory‑management maintainer David Hildenbrand supported this approach.

In the critical function filemap_read_rcu_batch(), Shutsemau further dissected the race‑condition hazard he discovered:

In the reference‑free RCU read path, the original patch’s logic first obtains the current folio and then reads the file size (i_size).

Shutsemau pointed out that there is a fatal timing gap here: when an old folio is evicted and replaced by a brand‑new folio, if another process happens to extend the file size (i_size) at that moment, the read path still uses the snapshot information of the now‑replaced old folio, but the calculation of the read boundary uses the newly extended i_size. This causes the read code to erroneously “overrun” into the newly expanded portion of the file that contains no valid data on disk or in memory, returning “unwritten data” directly to the user program.

To eliminate this timing hazard, Torvalds proposed a clear refactoring direction: the read of the file size (i_size) must be moved earlier, and the subsequent validity check of the folio should be merged with the boundary logic. Shutsemau fully adopted this improvement and smoothly incorporated the logic into the revised patch.

Reference links:

https://www.phoronix.com/news/Linus-Torvalds-Claude-Code

https://thenewstack.io/torvalds-claude-code-kernel/

Disclaimer: This article is compiled by InfoQ,does not represent the platform’s views, nor does it constitute investment advice; reproduction is prohibited without permission.

 Conference Recommendations

Jensen Huang talks about Chinese AI companies: the scarcer the compute, the more it forces them to perfect their architecture

Just now, Qianwen Office storms into e‑commerce operations! Store setup cost reduced from 30,000 to a few hundred yuan, one agent manages multi‑platform businesses

Just now, Google Gemini 4 went full throttle: API half‑price for a limited time, cache slashed by 95%, and a self‑built simulation taught the robot to score seven consecutive balls

Are you also “watching”? 👇