Kernel: Rust Difficulties, Spinlocks, and String Handling
-
LWN ☛ Rust code review and netdev
A fast-moving patch set—seemingly the norm for Linux networking development—seeks to add some Rust abstractions for physical layer (PHY) drivers. Lots of review has been done, and the patch set has been reworked frequently in response to those comments. Unfortunately, the Rust-for-Linux developers are having trouble keeping up with that pace. There is, it would appear, something of a disconnect between the two communities' development practices.
-
LWN ☛ Deferred scheduling for user-space critical sections
User-space developers working with highly threaded applications would often like to be able to use spinlocks to protect shared data structures from concurrent access. There is a fundamental problem with user-space spinlocks, though: there is no way to prevent a thread from being preempted. Various ways of working around this problem have been explored, but this patch from Steven Rostedt questions the premise on which much of that work is based: what if it were possible to prevent preemption, for a short period at least?
Spinlocks are fast when there is no contention, and they can be acquired with no help from the kernel at all. The contended case is more problematic, though. A normal spinlock implementation would "spin" — repeatedly poll the state of the lock until it becomes available — in this case. But if the holder of the lock has been preempted and is not running, that spinning could go on indefinitely, wasting CPU time. Worse, the spinning thread might be the one that preempted the lock holder; in that case, spinning actively prevents the lock from being released. Either way, spinning on a lock held by a thread that is not running can ruin the performance of a system.
-
LWN ☛ Better string handling for the kernel
The C programming language is replete with features that seemed like a good idea at the time (and perhaps even were good ideas then) that have not aged well. Most would likely agree that string handling, and the use of NUL-terminated strings, is one of those. Kernel developers have, for years, tried to improve the handling of strings in an attempt to slow the flow of bugs and vulnerabilities that result from mistakes in that area. Now there is an early discussion on the idea of moving away from NUL-terminated strings in much of the kernel.
The biggest problem with NUL-terminated strings is that they carry no information about the size of the buffer that contains them; that makes it easy to create buffer overflows. Over the years, a number of APIs have been created in an attempt to address this problem, adding functions like strncpy(), strlcpy(), and strscpy(), each of which is claimed to be better than its predecessors. None of them change the core concept of a NUL-terminated string, though, and none of them pleases everybody.
Over the years, the kernel has seen a long series of patches exchanging calls from one set of string functions for another. Sometimes those conversions have introduced bugs of their own, and maintainers have not always been happy with this work.