---
title: 'In the News: October 14, 2026 (Midday)'
description: 'Linus Torvalds posted a ten-patch Linux page-cache series he built with an LLM; a reviewer found a race within four hours.'
canonical_url: 'https://darkfactory.dev/news/2026-10-14-midday'
markdown_url: 'https://darkfactory.dev/news/2026-10-14-midday.md'
collection: news
date_published: '2026-10-14T13:30:00-04:00'
date_modified: '2026-10-14T13:30:00-04:00'
---

# In the News: October 14, 2026 (Midday)


One item at midday: Linus Torvalds has put up a ten-patch Linux kernel series that he says he built with the help of a large language model, and the first review turned up a race condition.

## 1. Torvalds posts an LLM-assisted kernel series with a 23x benchmark gain and a race already found

**[Improve page refcount scalability](https://lwn.net/ml/all/CAHk-=wjLjgfwgSZ1RDk4YdNFcV0ntosMO5AmBoHD76Zb3HFY7Q@mail.gmail.com/)** · Linus Torvalds, Linux kernel mailing list · October 13, 2026 ([LWN summary](https://lwn.net/Articles/1100449/))

Torvalds writes that, ahead of this year's kernel maintainer summit, he decided to "actually *solve*" a long-running page-cache scalability problem "using an LLM to help with the issues these things have had." The series makes the kernel delay freeing hot folios by one RCU period, so a plain `read()` can copy data from the page cache without taking a reference count. His headline figure is "a 23x performance increase on my Ryzen threadripper," and a table in the commit message shows reads per second at 64 threads rising from 13.3 million to 304 million. He calls it "not a real number in the sense that no real load will ever see it": the benchmark rereads the same small part of a page in a threaded loop on every CPU.

The post does not name the model or tool. Torvalds notes that the commit messages "are a bit more verbose than I would have done it myself without tool use." He did not mail the individual patches. The code sits in the `rcu-free-v3` branch of his public tree, and he asks for comments.

Kiryl Shutsemau replied about four hours later with a race in `filemap_read_rcu_batch()`. If a folio is replaced and the file size then grows, a reader can copy data that was never written to that location. His message includes a one-line fix, a recheck that the folio is still in the page cache after the size is read. LWN reports the review "has already identified a race condition in the code, though, so further work will be needed." We read the cover post, the LWN summary and the race report. We did not read the patches themselves or any of the rest of the thread.

**Why it matters:** This is a first-party account from the kernel's top maintainer of an LLM-assisted change: a measured gain on a deliberately artificial benchmark, then a human reviewer finding a correctness bug within hours. For anyone deciding how far to trust agent-written systems code, the review caught what the benchmark could not. Torvalds's own caveat on the number is the part to keep.