Linus Torvalds & Claude Code Fix Kernel Cache Contention, But Race Condition Found

Linus Torvalds's Shift on AI

At the 2024 Vienna Open Source Summit, Linus Torvalds dismissed generative AI as "90% marketing, 10% reality." At the 2026 North America Open Source Summit, he compared AI code generation to compilers: "You don't see people bragging that compilers replaced programmers." At the 2026 Prague Open Source Summit, he stated: "I actually really like using AI," while cautioning that critical work demands extreme care.

The 18-Month Page Cache Contention Problem

In the Linux kernel, the page cache caches disk files in memory. When a process reads a cached file, the kernel must prevent the memory page (called a folio) from being freed mid-read. The traditional method increments an atomic reference count, copies data, then decrements the count. On single-core systems this worked fine, but on modern many-core servers, dozens of cores simultaneously reading the same hot file hammer the same cache line holding the reference counter, causing severe cross-core cache-line bouncing . CPU cycles are wasted synchronizing the counter instead of reading data.

Oracle kernel engineer Matthew Wilcox first highlighted this in a February 2024 email ( https://lore.kernel.org/linux-mm/20240225.../). Over the next 18 months, Wilcox, Linus, and other top developers attempted hand-written patches but hit various obstacles.

Linus's Experiment: Claude Code as Implementation Partner

On October 11, 2026, Linus pushed an experimental branch noref-filemap-read-with-llm to his personal repo. The commit message read: "The code, test programs, review of the above issues, and the initial draft of this text were all done by an LLM coding assistant ( Claude Code ) under my guidance. Test data run on my machine."

Linus directed Claude Code to produce four deliverables:

Eight kernel patches implementing the fix

A multi-core benchmark program to saturate the read path

A self-review listing potential risks and open issues

A detailed cover letter explaining the changes

Technical Solution: RCU and PG_rcu_free

The patches remove reference-count manipulation entirely from the common buffered-read path. Instead, they rely on the kernel's RCU (Read-Copy-Update) mechanism and introduce a new page flag PG_rcu_free. When a page is evicted from the page cache, it is not immediately freed; RCU guarantees it stays valid until all pre-existing RCU read-side critical sections exit. This eliminates the shared counter and the associated cache-line bouncing.

Benchmark Results (8 threads reading same file, 16 bytes each)

Metric                              Before (Linux 7.3-rc6)    After (Claude Code assisted)    Change
Read throughput (reads/sec)         9.9M – 10.4M              30M – 33M                       ~3x increase
Cycles per read                     2,937 – 2,975             725 – 726                       75% reduction
Cross-core cache contention         30,538                    101                             99.6% reduction
(perf c2c HITMs)                                                                    
Single-thread unmapped user-page    ~4,150 cycles             ~6,550 cycles                   58% slower
read (regression)

The optimization dramatically improves the hot multi-core path at the cost of a slower cold single-thread path.

Critical Race Condition Found in Review

On October 13, kernel developer Kiryl Shutsemau identified a race in filemap_read_rcu_batch(). The scenario:

Thread A reads the last page of a file without a reference count.

Memory reclaim evicts that page from the cache; RCU keeps the memory alive but the page is no longer associated with the file, and parts may be uninitialized.

Thread B truncates the file and immediately extends it, increasing i_size.

Thread A checks i_size, sees the larger size, and copies the stale/uninitialized memory to userspace.

This is a silent data corruption / kernel information leak vulnerability triggered only under extreme concurrency.

Architectural Critique from Matthew Wilcox

Wilcox argued that dedicating a precious page flag ( PG_rcu_free) to this single read path is architecturally inelegant and questioned the handling of large folio splitting boundaries.

Human Takeover: rcu-free-v3 Branch

Linus accepted the flaws. Shutsemau took over the patch set, retaining the core RCU idea but completely rewriting the page-freeing and synchronization logic, producing a new rcu-free-v3 branch.

Conclusion

Claude Code enabled Linus to produce a complete, benchmarked patch series in days for a problem that had resisted human experts for 18 months. However, the AI could not foresee the intricate race condition that only deep kernel concurrency expertise could uncover. The episode demonstrates that AI acts as a powerful accelerator for implementation grunt work, but final correctness in safety-critical systems still requires human judgment and rigorous peer review.