Kernel Coverage in LWN
-
The rest of the 6.2 merge window [LWN.net]
The world got a special Christmas present from Linus Torvalds this year in the form of the 6.2-rc1 kernel prepatch. By the time the merge window closed, 13,687 non-merge changesets had been pulled into the mainline for the 6.2 release. This was the busiest merge window since 5.13 (which brought in 14.231 changesets) in mid-2021, and quite a bit busier than 6.1 was — but comparable to the late 5.x releases. Just under 4,000 of those changesets were pulled after the first-half summary was written; there were quite a few significant changes to be found in those late-arriving patches.
-
SLOB nears the end of the road [LWN.net]
The kernel project tries hard to avoid duplicating functionality within its code base; whenever possible, a single subsystem is made to serve all use cases. There is one notable exception to this rule, though: there are three object-level memory allocators ("slab allocators") in the kernel. The desire to reduce the count has been growing stronger over the years, and some steps have been taken in 6.2 to eliminate the least-loved allocator — SLOB — in the relatively near future.
The job of a slab allocator is to provide the kernel with (usually) small chunks of memory in an efficient way. The heavily used kmalloc() function is implemented by the slab allocator, but there is also a lower-level API specialized for the management of numerous objects of the same size. It is quite common for a kernel subsystem to need to allocate instances of a given structure, for example; all of those instances are normally the same size and can be managed in a slab.
The kernel's oldest slab allocator is typically just called SLAB (though the name is not an acronym); it has been there in one form or another since nearly the beginning. SLAB is intended to be a general-purpose allocator suitable for most workloads, and serves that purpose reasonably well.
-
Adding system calls for Linux security modules [LWN.net]
The Linux security module (LSM) subsystem has long had limitations on which modules could be combined in a given running kernel. Some parts of the problem have been solved over the years—"smaller" LSMs can be combined at will with a single, more complex LSM—but combining (or "stacking") SELinux with, say, Smack or AppArmor has never been possible. Back in October, we looked at the most recent attempt to add that ability, which resulted in patches to add two new system calls for LSM. By the end of December, the number of new system calls had risen to three.
The underlying problem that Casey Schaufler is trying to solve is the handling of the multiple security contexts and how to report them to user space; that is one of the barriers to stacking two or more context-using LSMs. These contexts are a string representation of the information used by an LSM to make its access-control decisions. Schaufler's efforts to fully solve the LSM-stacking problem have now stretched over the last ten years.
-
Welcome to 2023 [LWN.net]
New kernel functionality written in Rust will be proposed for inclusion into the mainline. While the initial support for Rust kernel code landed in the 6.1 kernel, it was far short of what is needed to add any interesting functionality to the kernel. As the support infrastructure is built up in coming releases, though, it will become possible to write a useful module that can be built for a mainline kernel. A number of interesting modules exist now and others are in the works; they just need the kernel to provide the APIs they depend on.
Pushing a module written in Rust for the mainline seems almost certain to spark a significant discussion. While many kernel developers are enthusiastic about the potential of Rust, there are others who are, at best, unconvinced. This latter group has gone quiet in recent times, presumably waiting to see how things play out. After all, as Linus Torvalds has said, the current Rust code is an experiment; if that experiment does not go well, the code can be taken out again.
The merging of a Rust module that people will actually use will be a tipping point, though. Once this code is merged, taking it back out would create the most obvious sort of regression; that, of course, is something that the kernel community goes far out of its way to avoid. So the merging of user-visible functionality written in Rust will mark the point where the Rust code can no longer just be torn out of the kernel; it will be a statement that the experiment has succeeded.
Anybody who is still unsure of the benefit of Rust support in the kernel will have to speak out before that happens, and some of them surely will. Reaching a consensus may take some time, to put it lightly. So, while it seems likely that this discussion will begin in 2023, it is far less likely that any user-visible functionality written in Rust will actually be merged this year.