LWN Articles About Linux Kernel
-
Reports from OSPM 2023, part 3
The fifth conference on Power Management and Scheduling in the Linux Kernel (abbreviated "OSPM") was held on April 17 to 19 in Ancona, Italy. LWN was not there, unfortunately, but the attendees of the event have gotten together to write up summaries of the discussions that took place and LWN has the privilege of being able to publish them. Reports from the third and final day of the event appear below.
-
Development statistics for 6.4
The 6.4 kernel was released on June 25 after a nine-week development cycle. By that point, 14,835 non-merge changesets had been pulled into the mainline kernel, a slight increase from 6.3 (14,424 changesets) but still lower than many other development cycles. As usual, LWN has taken a look at those changesets, who contributed them, and what the most active developers were up to.
The work in 6.4 was contributed by 1,980 developers, 282 of whom made their first kernel contribution during this development cycle.
-
Converting filesystems to iomap
A discussion that largely centered around the documentation of iomap, which provides a block-mapping interface for modern filesystems, was led by Luis Chamberlain at the 2023 Linux Storage, Filesystem, Memory-Management and BPF Summit. There is an ongoing process of converting filesystems to use iomap, in order to leave buffer heads behind and to better support folios, so the intent was to get feedback on the documentation from developers who are working on those conversions. One of the concrete outcomes of the session was a plan to move that documentation from its current location on the KernelNewbies wiki into the kernel documentation.
Hannes Reinecke said that the lack of clear units in the iomap documentation confused him; were things specified in bytes, sectors, pages, or something else? In addition, there are many different operation-function pointers, in three different struct *_ops, that need to be provided by a filesystem, but it was not clear to him what each of them was meant to do. Chamberlain said that it had also confused him when he started looking at iomap, but the basic idea is that there are lots of different types of operations, many with flags or options of various sorts, so the myriad of ops are just meant to split those out into their own separate functions. The alternative is a single function with lots of complexity to handle all of the different possibilities. Reinecke said that he was fine with having all of those functions, but that the documentation did not (yet) explain what all the operations were for.
-
Removing the kthread freezer
The final day of the 2023 Linux Storage, Filesystem, Memory-Management and BPF Summit featured three separate sessions led by Luis Chamberlain (he also led a plenary on day two); the first of those was a filesystem session on the status of the kthread-freezer-removal effort. The kthread freezer is meant to help filesystems freeze their state in order to suspend or hibernate the system, but since at least 2015, the freezer has been targeted for removal. Things did not change much a year later, nor by LSFMM in 2018 when Chamberlain had picked up Jiri Kosina's removal effort; this year, Chamberlain was back to try to push things along.
It may come as a surprise to some that freezing filesystems in preparation for suspending the system has been broken in Linux for years, he began. There is no unified mechanism to freeze filesystems and if there is a lot of I/O going on, it can lead to a system hang when resuming, which is not quite what users are looking for.
-
Delegating privilege with BPF tokens
The quest to enable limited use of BPF features in unprivileged processes continues. In the previous episode, an attempt to use authoritative Linux security module (LSM) hooks for this purpose was strongly rejected by the LSM developers. BPF developer Andrii Nakryiko has now returned with a new mechanism based on a privilege-conveying token. That approach, too, has run into some resistance, but a solution for the strongest concerns might be in sight.
Nakryiko (and his employer) would like the ability to allow a process to carry out a limited set of BPF operations without needing to hold any special capabilities. Currently, most BPF operations require (at least) the CAP_BPF capability, so code that needs to use BPF functionality must be run with privilege that often goes beyond what is actually needed. The security module implemented in Nakryiko's previous attempt could have been used to allow specific operations as controlled by the security policy, but this module required authoritative hooks (security hooks that grant access that would otherwise be denied); such hooks are not allowed in the kernel. Thus, necessarily, the new approach takes a different tack.