There are many applications that need to be able to write multi-block chunks of data to disk with the assurance that the operation will either complete successfully or fail altogether — that the write will not be partially completed (or "torn"), in other words. For years, kernel developers have worked on providing atomic writes as a way of satisfying that need; see, for example, sessions from the Linux Storage, Filesystem, Memory Management, and BPF (LSFMM+BPF) Summit from 2023, 2024, and 2025 (twice). While atomic direct I/O is now supported by some filesystems, atomic buffered I/O still is not. Filling that gap seems certain to be a 2026 LSFMM+BPF topic but, thanks to an early discussion, the shape of a solution might already be coming into focus.

Toke Høiland-Jørgensen has posted an overview of how zero-copy networking works in the Linux kernel.

Since the memory is being copied directly from userspace to the network device, the userspace application has to keep it around unmodified, until it has finished sending. The sendmsg() syscall itself is asynchronous, and will return without waiting for this. Instead, once the memory buffers are no longer needed by the stack, the kernel will return a notification to userspace that the buffers can be reused.

Motorola has announced that it will be working with the GrapheneOS Foundation, a producer of a security-enhanced Android distribution. "Together, Motorola and the GrapheneOS Foundation will work to strengthen smartphone security and collaborate on future devices engineered with GrapheneOS compatibility.". LWN looked at GrapheneOS last July.

The 7.0-rc2 kernel prepatch is out for testing. According to Linus:

So I'm not super-happy with how big this is, but I'm hoping it's just the random timing noise we see every once in a while where I just happen to get more pull requests one week, only for the next week to then be quieter.