I recently presented a brief tribute to Andrew Morton at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit; it included a suggestion that reading (or re-reading) his 2004 Ottawa Linux Symposium keynote would be instructive. This talk, given immediately after the Kernel Summit session that decided to fundamentally change the kernel's development model, tells a lot about how the kernel project got to where it is today. The text of that speech was hosted on Groklaw, and has since been replaced by crypto spam, which is rather less useful. In the hopes of preserving this seminal moment, the transcript has been rescued from the Wayback Machine and is presented here.
The mapcount field was created to track the number of mappings (page-table entries) that refer to the given page. Among other things, a mapcount of zero means that the page has no references and can be reclaimed. Maintaining mapcount has become increasingly challenging and expensive as the memory-management system has grown in complexity, so Hildenbrand has been looking for ways to get rid of it. This session was, he said, maybe one of the last times he will have to bring up this topic.
Rodrigo Arias Mallo, maintainer of the Dillo web browser, has written a blog post with a proposal on one way to ensure that a contribution is written by a human and not AI; he suggests asking new contributors to record their programming session using asciinema. In the same way that LLMs generate patches, they can also generate the asciinema recordings themselves. Then, the contributors can lie to the reviewers pretending to have made the edits. Perhaps surprisingly, this is not a easy task for LLMs, at least from my observations. The corpus of recordings of developers making mistakes and thinking the whole process of editing a file is not as large as the corpus of FOSS programs and patches in which to train an LLM. During my very simple tests I haven't been able to generate an asciinema session that remotely resembles what I would expect from a human, and even less so from a human with a nice editor theme and editing an existing Dillo source file. The Dillo project is not yet requiring
Curl maintainer Daniel Stenberg writes about the stress of keeping up with the current flood of security reports. This is a never-before seen or experienced pressure on the curl project and its security team members. An avalanche of high priority work that trumps all other things in the project that is primarily mental because we certainly could ignore them all if we wanted, but we feel a responsibility, we have a conscience and we are proud about our work. We feel obliged to fix security problems in the software we have helped shipped to every device on the globe. This is personal to us. With about half the release cycle left until the pending release ships, we already have twelve confirmed vulnerabilities meaning twelve pending CVE announcements. That's a new project record and it also means we will reach thirty published CVEs in 2026 even before half the calendar year has passed. The projected total amount of curl CVEs published through the whole year is therefore at least double th
Huge pages can improve performance by increasing translation lookaside buffer (TLB) utilization and reducing memory-management overhead. Transparent huge pages (THPs) are supposed to make huge-page usage, well, transparent, Nico Pache said at the beginning of his session in the memory-management track of the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit. That transparency has never worked as well as many would like; he has been working on improvements to make it easier for applications to use huge pages on Linux systems. A following session, led by David Hildenbrand, was focused on how THPs could be taken away from processes that are not using them fully.
In a plenary session at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, the state of patch review using large language models (LLMs) was discussed. It is a topic that has been swirling around in the kernel community for much of the year. The plenary, which was led by Roman Gushchin, Chris Mason, Josef Bacik, and Sasha Levin, resulted in a quite bit of discussion, so much that a second filesystem-track-only (though others surely sat in) slot was used to continue it later in the day.
The Software Freedom Conservancy (SFC) published a news item on May 18 about its response to violations of the AGPLv3 by Bambu Lab in its 3D printers. The company has not provided the source code to its modifications to a 3D "slicer" program that was released under the AGPLv3 and it has also threatened Paweł Jarczak who created a fork of a different slicer (Orca Slicer) released under AGPLv3 in order to interoperate with his Bambu printer. Based on that, the SFC has created the baltobu project aimed at reverse-engineering and reimplementing the Bambu code while also hosting the Orca Slicer fork. Bambu has behaved badly for years and made multiple, provably false public statements regarding the AGPLv3 and its requirements. The recent aggressive behavior toward Paweł Jarczak was a last straw for us: we have decided to launch a multi-pronged effort that will assist consumers and users in the short-term, and also work toward a long-term strategy to improve the software right to repair for
Joshua Hahn began his session in the memory-management track of the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit by saying that the memory controller for control groups is intended to provide resource allocation, accounting, and protection from interference by other tasks. But it was not really designed for tiered-memory systems; he is looking for a way to improve that situation.
Linus Torvalds does not enjoy giving talks, but he does consent to the occasional on-stage conversation with Dirk Hohndel at Linux Foundation events. The pair held the 30th of their fire-less fireside chats during a keynote session on May 20, at the 2026 Open Source Summit North America. Topics included 3D printing, guitar pedals, the recent 7.1-rc4 release of the kernel, and Torvalds's complicated relationship with AI tooling.
The 7.1-rc5 kernel prepatch is out for testing. Quoth Linus: I'm not entirely happy about it - most of this is totally trivial stuff to random drivers, which obviously makes it all less scary, but at the same time I'm really not convinced the churn is worth it at rc5 time. These things are "fixes", sure, but at the same time a lot of them are simply so irrelevant that I think they'd be better off in a linux-next tree and get merged during the merge window. So I think I'll start being a bit more hardnosed about this kind of unnecessary churn this late in the game. We are supposed to look for *regressions*. Non-critical fixes to long-standing issues are simply not appropriate for this late in the release cycle. End result: this is too big, and this is the heads-up that I'll be pushing back on pointless pull requests with fixes that just aren't that important. And yes, several of these series were triggered by AI code review.
The 7.0.10, 6.18.33, 6.12.91, 6.6.141, 6.1.174, 5.15.208, and 5.10.257 stable kernel updates have all been released. The first four are huge (the 7.0.10 review version had 1,146 commits) while 6.1.174, 5.15.208, and 5.10.257 are small updates for the "Fragnesia" vulnerability.
The kernel's page cache is charged with maintaining pages (or, more correctly, folios) containing copies of data from files in the filesystem; its performance has a big effect on the performance of the system as a whole. One of the key decisions the kernel must make is when to evict folios from the page cache. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Tal Zussman ran a memory-management-track session on how the page cache could be better customized for specific workloads. It will not be much of a spoiler to say that it involves BPF.
Linux News