New LWN Articles on Kernel
-
On Rust in enterprise kernels
At the recently concluded Maintainers Summit, it was generally agreed that the Rust experiment would continue, and that the path was clear for more Rust code to enter the kernel. But the high-level view taken at such gatherings cannot always account for the difficult details that will inevitably arise as the Rust work proceeds. A recent discussion on the nouveau mailing list may have escaped the notice of many, but it highlights some of the problems that will have to be worked out as important functionality written in Rust heads toward the mainline.
-
Two pidfd tweaks: PIDFD_GET_INFO and PIDFD_SELF
The pidfd mechanism, which uses file descriptors to refer to processes in an unambiguous and race-free way, was first introduced in 2018. Since then, the interface has gained a number of new features, but development has slowed over time as the interface has matured. There are, however, a couple of patches in circulation that are meant to make working with pidfds simpler in some situations.
-
FFI type mismatches in Rust for Linux
At Kangrejos, Gary Guo wanted to discuss three problems with the way Rust and C code in the kernel interact: mismatched types, too many type casts, and the overhead of helper functions. To fix the first two problems, Guo proposed changing the way the kernel maps C types into Rust types. The last problem was a bit trickier, but he has a clever workaround for that, based on tricking the compiler into inlining the helper functions across language boundaries.
-
Zapping pointers out of thin air
Paul McKenney gave a presentation at Kangrejos this year that wasn't (directly) related to Rust. Instead, he spoke about the work he has been doing in concert with many other contributors on improving the handling of subtle concurrency problems in C++. Although he cautioned that his talk was only an overview, and not a substitute for reading the relevant papers, he hoped that the things the C++ community is working on would be of interest to the Rust developers present as well, and potentially inform future work on the language. McKenney's talk was, as is his style, full of subtle examples of weird multithreaded behavior. Interested readers may wish to refer to his slides in an attempt to follow along.
-
Using LKMM atomics in Rust
Rust, like C, has its own memory model describing how concurrent access to the same data by multiple threads can behave. The Linux kernel, however, has its own ideas. The Linux kernel memory model (LKMM) is subtly different from both the standard C memory model and Rust's model. At Kangrejos, Boqun Feng gave a presentation about the need to reconcile the memory models used by Rust and the kernel, including a few potential avenues for doing so. While no consensus was reached, it is an area of active discussion.
The problem, Feng explained, is that the LKMM makes guarantees that the Rust memory model does not. Since the compiler doesn't know about those guarantees, it can (potentially) make optimizations that break them. The only saving grace is the ABI between C and Rust code, which should have certain guarantees that both sides are aware of. However, in practice, many architectures don't specify any guarantees about atomic operations or interactions between threads as part of their ABI. Having an ABI that listed the relevant guarantees wouldn't be a complete solution in any case — cross-language link-time-optimization (LTO) could still cause problems, Feng said.