LWN Articles About Linux Kernel Development

posted by Roy Schestowitz on Jun 05, 2025

• LWN ☛ Development statistics for the 6.15 kernel

  The 6.14 kernel development cycle only brought in 11,003 non-merge changesets, making it the slowest cycle since 4.0, which was released in 2015. The 6.15 kernel, instead, brought in 14,612 changesets, making it the busiest release since 6.7, released at the beginning of 2024. The kernel development process, in other words, is back up to full speed. The 6.15 release happened on May 25, so the time has come for the obligatory look at where the changes in this release came from.

  As a reminder, LWN subscribers can find this information and more, at any time, for any kernel version since 2005, in the LWN Kernel Source Database.

• LWN ☛ Long-duration stress-testing for filesystems

  Testing filesystems is a frequent topic at the Linux Storage, Filesystem, Memory Management, and BPF Summit (LSFMM+BPF); the 2025 edition was no exception. Boris Burkov led a filesystem-track session to discuss stress-testing filesystems—and running those tests for lengthy periods. He reviewed what he has been doing when testing filesystems and wanted to gather ideas for what could be done to catch more bugs before the filesystems hit production.

  He began by noting that he works for Meta on Btrfs, which means that he spends a lot of time tracking down ""weird bugs that you only see on millions of computers"". Production use stresses filesystems, so it makes sense for filesystem developers to do that stressing ahead of time to try to catch bugs before they reach production. To get an idea of what kinds of bugs made it into production, he surveyed ones that Meta had encountered; ""it was a quick biased sample"" that may miss some types of bugs or overemphasize others. There were two data-corruption bugs, a metadata corruption that ""took a few months of Josef [Bacik] and I debugging it to find"", a noisy-neighbor problem where misbehaving containers could cause a problem in other containers due to CPU and global-lock contention, and corruption when trying to enable large folios on XFS.

• LWN ☛ Formally verifying the BPF verifier

  The BPF verifier is an increasingly complex and security-critical piece of code. When the kinds of people who are apt to work on BPF see a situation like that, they naturally question whether it's possible to use formal verification to ensure that the implementation of the code in question is correct. Santosh Nagarakatte led the first of two extra-long sessions in the BPF track of the 2025 Linux Storage, Filesystem, Memory Management, and BPF Summit about his team's work formally verifying the BPF verifier with a custom tool called Agni.

• LWN ☛ Verifying the BPF verifier's path-exploration logic

  Srinivas Narayana led a remote session about extending Agni to prove the correctness of the BPF verifier's handling of different execution paths as part of the Linux Storage, Filesystem, Memory Management, and BPF Summit. The problem of ensuring the correctness of path exploration is much more difficult than the problem of ensuring the correctness of arithmetic operations (which was the subject of the previous session), however. Narayana's plan to tackle the problem makes use of a mixture of specialized techniques — and may need some assistance from the BPF developers to make it feasible at all.

  Path exploration is a key component of the BPF verifier, Narayana said. It's what makes it practical for the verifier to infer precise bounds for registers even in the presence of conditionals and loops. The brute-force approach to path exploration would be to consider every possible path through the program. That means considering a number of paths exponential in the number of conditionals, which would be slow.

  Instead, the verifier is somewhat selective about exploring paths: it attempts to explore only paths that are essentially different from other paths that have already been considered. In other words, if the register values along a path are a subset of what has already been checked, the verifier can avoid exploring that path because it knows the BPF program has already been verified under more general preconditions.

  This optimization substantially speeds up the verification of programs with complex control flow; it's also quite complicated to implement correctly, and has already resulted in at least one security problem. Narayana wants to use Agni to show that the current path-pruning logic is implemented correctly.

• LWN ☛ Allowing BPF programs more access to the network

  Mahé Tardy led two sessions about some of the challenges that he, Kornilios Kourtis, and John Fastabend have run into in their work on Tetragon (Apache-licensed BPF-based security monitoring software) at the Linux Storage, Filesystem, Memory Management, and BPF Summit. The session prompted discussion about the feasibility of letting BPF programs send data over the network, as well as potential new kfuncs to let BPF firewalls send TCP reset packets. Tardy presented several possible ways that these could be accomplished.

• LWN ☛ Reports from OSPM 2025, day two

  The seventh edition of the Power Management and Scheduling in the Linux Kernel Summit (known as "OSPM") took place on March 18-20, 2025. Topics discussed on the second day include improvements to device suspend and resume, the status and future of sched_ext, the scx_lavd scheduler, improving the efficiency of load balancing, and hierarchical constant bandwidth server scheduling.