Since the earliest days of Unix, two of the core process-oriented system calls have been fork(), which creates a child process as a copy of the parent, and exec(), which runs a new program in the place of the current one. In Linux kernels, those system calls are better known as clone() and execve(), but the core functionality remains the same. While there is elegance to this process-creation model, there are shortcomings as well. A recent proposal from Li Chen to add "spawn templates" to the kernel will not be accepted in its current form, but it may point the way toward a new process-creation primitive in the future.

The Software Engineering Radio podcast has put up an interview with graphics maintainer Dave Airlie. Much of what is in there will not be news to LWN readers, but it is an interesting overview of the life of a large-subsystem maintainer.

I was talking to a few of the Rust people, and I thought: these are very young people, these are a group of people in their 20s, maybe 30s, they are a younger cohort of developers than the people I am normally used to dealing with. I thought there was maybe a good way we could bring these groups together. I think that having young people coming into the kernel using Rust is valuable... So I thought that I should be supportive of bringing Rust into the kernel.

The splice() and vmsplice() system calls are meant to improve performance for certain data-movement tasks by minimizing (or avoiding altogether) system calls and the copying of data. They also have a long history of security problems. The recent flood of LLM-discovered vulnerabilities has drawn attention, once again, to splice() and vmsplice(); as a result, they may end up being removed altogether.

The DistroWatch site is celebrating its 25th anniversary. "All in all, it has been an incredible ride. Many of you who read these pages regularly know that downloading and testing distributions is a highly addictive pastime. I have been an avid distro-hopper for the last 25 years and I don't see myself abandoning this activity for many more years to come." Congratulations to Ladislav Bodnar and all the others who have kept that resource going for so long.

The x32 ABI was meant to be the best of both worlds, providing the expanded registers and instruction set of the x86-64 architecture while preserving the lower memory use of 32-bit systems. The Linux kernel has supported x32 since the 3.4 release in 2012. The initial excitement around x32 did not last, though, and kernel developers are considering removing that support — and not for the first time. Even the most unloved features tend to have a few users, though, making removal hard.

The 7.1-rc6 kernel prepatch is out for testing. Linus said: "Well, I wouldn't call this 'small', but it is certainly smaller than rc5 was. And I don't think there's anything particularly scary here, so maybe we're still on track for a normal release cycle. Let's see."

Version 1.96.0 of the Rust programming language has been released. Changes include a new set of Copy-implementing Range types, assertions with pattern matching, a number of stabilized APIs, and two Cargo vulnerability fixes.

IBM has sent out a press release touting a claimed $5 billion investment into an operation called Project Lightwell:

Project Lightwell will establish a trusted enterprise clearinghouse combined with a global force of engineers to identify and fix vulnerabilities at scale. The clearinghouse will serve as a security coordination layer, using advanced AI capabilities to validate and test fixes across an unprecedented volume of open source code. These capabilities will be offered through commercial subscriptions, allowing enterprises to integrate secure patches directly into their existing software supply chains with enterprise-grade validation and lifecycle management.

Toward the bottom, it does also mention sharing vulnerability information with upstream projects.

The kernel's memory-management subsystem is currently partway through a multi-year project to replace the page structure (which represents a page of physical memory) with memory descriptors. At the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Vishal Moola ran a fast-paced session in the memory-management track to describe the current state of that work and what is likely to happen next.

Inside this week's LWN.net Weekly Edition:

• Front: Dirk and Linus talk; BPF and GCC; private memory modes; BPF page-cache policies; major page faults; LLM kernel review; tiered-memory support; transparent huge pages; page mappings; Model Openness Tool.
• Briefs: Stenberg security stress; GTK PDF problems; Morton 2004 keynote; OpenBSD 7.9; Bambu's AGPLv3 violations; Quotes; ...
• Announcements: Newsletters, conferences, security updates, patches, and more.

The Linux Foundation will be hosting a live interview with LWN co-founder Jonathan Corbet. The event will take place on Tuesday, June 2 at 8:00AM Pacific daylight time (UTC-7). Registration is open for those who would like to attend.

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 thanks to 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.

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 this number!

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.

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.

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.

A major page fault occurs when a process attempts to access a page that is not currently present in RAM; satisfying such faults usually involves I/O, and can thus take some time. When many threads sharing an address space are generating page faults, the result can be significant lock contention while that I/O takes place. During the memory-management track at the 2026 Linux Storage, Filesystem, Memory Management, and BPF Summit, Barry Song led a session to try, yet again, to find an enduring solution to this problem.