Alexei Starovoitov gave "less of a presentation, more of a scream of realization" at the BPF track of the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit. He shared a set of ideas for how BPF could change to avoid being swept away by the sea-change in programming represented by modern large language models (LLMs) and the coding agents based on them. In a follow-up session, the discussion covered more problems with how coding agents use tools like bpftrace, and the current deluge of patches in need of review in the BPF subsystem.

Optimizing compilers can, under some circumstances, infer when a parameter to a function is not needed, and remove it. This is all well and good until the kernel's tracing or BPF subsystems need information on how to call the function or where its arguments are stored. Alan Maguire and Yonghong Song spoke at the 2026 Linux Storage, Filesystem, Memory-Management, and BPF Summit about their work on recording information regarding changed function signatures in the kernel's BTF debugging information, to better support tracing such functions.

MeshCore is a relatively new project, started in January 2025, that aims to build a scalable mesh network using low-power long-distance radios. While many other projects of the same general nature have been tried before, MeshCore grew quickly because of its more efficient message routing and enthusiastic community. In early 2026, an early proponent of the project made a sudden shift that left the rest of the community stunned and embroiled in a trademark dispute.

José Marchesi and the GCC-BPF developers opened the BPF track at the 2026 Linux Storage, Filesystem, Memory-management, and BPF Summit with a 90-minute summary of what has changed for GCC's BPF support in the past year. This kind of session has become something of a tradition. There were similar updates in 2025 and 2024. This time around, GCC seems to be closing in on feature parity with the LLVM toolchain — as the slides detail.

A recent patch set from Steffen Eiden and others has set the groundwork for allowing hardware-assisted emulation of Arm CPUs on s390 CPUs. Version two of the posting fixes a handful of smaller problems, but does not differ much. The patches were welcomed by the Arm maintainers, pending some discussion of how the collaboration between the architectures could be structured to prevent maintainability problems on the Arm side. When those details are resolved, the patches could pave the way for transparently running Arm-based virtual machines (VMs) on s390 hosts at native or near-native speeds.

Modern database and filesystems make pervasive use of B-trees, which are tree structures optimized for storing sorted lists of keys and values on block devices. Dolt is an Apache 2.0-licensed project that makes clever use of a variant of a B-tree to support efficient version control for an entire database. The data structure it uses could well be of interest to other projects.

Security analysis firm Xint has disclosed a security bug in the Linux kernel that allows for arbitrary 4-byte writes to the page cache, and which has been present since 2017. The vulnerability has been fixed in mainline kernels. A proof-of-concept script demonstrates how to use the flaw to corrupt a setuid binary, which works on multiple distributions, by requesting an AEAD-encrypted socket from user space and splicing a particular payload into it. A supplemental blog post gives more details about the discovery and remediation.

A core primitive underlying this bug is splice(): it transfers data between file descriptors and pipes without copying, passing page cache pages by reference. When a user splices a file into a pipe and then into an AF_ALG socket, the socket's input scatterlist holds direct references to the kernel's cached pages of that file. The pages are not duplicated; the scatterlist entries point at the same physical pages that back every read(), mmap(), and execve() of that file.

Version 0.16.0 of the Zig programming language was recently announced, and with it an expanded version of the new Io interface that we covered in December. The new interface is based on an idea called structured concurrency that makes writing correct concurrent applications easier. Zig's implementation of the idea is more explicit and verbose than other languages, however, which could offer an opportunity to explore the consequences of different designs.

In Rust, types either possess a constant size known at compile time, or a dynamically calculated size known at run time. That is fine for most purposes, but recent proposals for the language have shown the need for a more fine-grained hierarchy. RFC 3729 from David Wood and Rémy Rakic would add a hierarchy of traits to describe types with sizes known under different circumstances. While the idea has been subject to discussion for many years, a growing number of use cases for the feature have come to light.

Shor's algorithm is the main practical example of an algorithm that runs more quickly on a quantum computer than a classical computer — at least in theory. Shor's algorithm allows large numbers to be factored into their component prime factors quickly. In reality, existing quantum computers do not have nearly enough memory to factor interesting numbers using Shor's algorithm, despite decades of research. A new paper provides a major step in that direction, however. While still impractical on today's quantum computers, the recent discovery cuts the amount of memory needed to attack 256-bit elliptic-curve cryptography by a factor of 20. More interesting, however, is that the researchers chose to publish a zero-knowledge proof demonstrating that they know a quantum circuit that shows these improvements, rather than publishing the actual knowledge of how to do it.

Many people dislike the proliferation of Large Language Models (LLMs) in recent years, and so make an understandable attempt to avoid them. That may not be possible in general, but there are two new forks of Vim that seek to provide an editing environment with no LLM-generated code. EVi focuses on being a modern Vim without LLM-assisted contributions, while Vim Classic focuses on providing a long-term maintenance version of Vim 8. While both are still in their early phases, the projects look to be on track to provide stable alternatives — as long as enough people are interested.

The idea of using large language models (LLMs) to discover security problems is not new. Google's Project Zero investigated the feasibility of using LLMs for security research in 2024. At the time, they found that models could identify real problems, but required a good deal of structure and hand-holding to do so on small benchmark problems. In February 2026, Anthropic published a report claiming that the company's most recent LLM at that point in time, Claude Opus 4.6, had discovered real-world vulnerabilities in critical open-source software, including the Linux kernel, with far less scaffolding. On April 7, Anthropic announced a new experimental model that is supposedly even better; which they have partnered with the Linux Foundation to supply to some open-source developers with access to the tool for security reviews. LLMs seem to have progressed significantly in the last few months, a change which is being noticed in the open-source community.

On March 31, Kees Cook shared a patch set that represents the culmination of more than a year of work toward eliminating the possibility of silent, unintentional integer overflow in the kernel. Linus Torvalds was not pleased with the approach, leading to a detailed discussion about the meaning of "safe" integer operations and the design of APIs for handling integer overflows. Eventually, the developers involved reached a consensus for a different API that should make handling overflow errors in the kernel much less of a hassle.

Not many people live on sailboats. Things may be better these days, but back in 2014 sailboat dwellers had to contend with lag-prone, intermittent, low-bandwidth internet connections. Dominic Tarr decided to fix the problem of keeping up with his friends by developing a delay-tolerant, fully distributed social-media protocol called Scuttlebutt. Nearly twelve years later, the protocol has gained a number of users who have their own, non-sailboat-related reasons to prefer a censorship-resistant, offline-first social-media system.

Brian "bex" Exelbierd has published a blog post exploring follow-up questions raised by the recent debate about the use of the LLM-based review tool Sashiko in the memory-management subsystem. His main finding is that Sashiko reviews are bi-modal with regards to whether they contain reports about code not directly changed by the patch set — most do not, but the ones that do often have several such comments.

Hypothesis 1: Reviewers are getting told about bugs they didn't create. Sashiko's review protocol explicitly instructs the LLM to read surrounding code, not just the diff. That's good review practice — but it means the tool might flag pre-existing bugs in code the patch author merely touched, putting those problems in their inbox.

Hypothesis 2: The same pre-existing bugs surface repeatedly. If a known issue in a subsystem doesn't get fixed between review runs, every patch touching nearby code could trigger the same finding. That would create a steady drip of duplicate noise across the mailing list.

I pulled data from Sashiko's public API and tested both.