Author Archives: paulmckrcu

Given the data-race-freedom guarantees of Rust’s non-unsafe code, one might reasonably argue that there is no point in the Kernel Concurrency Sanitizer (KCSAN) analyzing such code. However, the Linux kernel is going to need unsafe Rust code, and although there … Continue reading →

Some of the previous posts in this series have been said to be quite difficult, so I figured I owed you all an easy one. And the zombie-pointer problem really does have a trivial solution, at least in the context … Continue reading →

Rust concurrency makes heavy use of ownership and borrowing. The purpose of this post is not to give an exposition of Rust’s capabilities and limitations in this area, but rather to give a series of examples of ownership in the … Continue reading →

Read-copy update (RCU) vaguely resembles a reader-writer lock [1], but one in which readers do not exclude writers. This change in semantic permits RCU readers to be exceedingly fast and scalable. In fact, in the most aggressive case, rcu_read_lock() and … Continue reading →

What Are Sequence Locks? Sequence locks vaguely resemble reader-writer locks except that readers cannot block writers. If a writer runs concurrently with a reader, that reader is forced to retry its critical section. If a reader successfully completes its critical … Continue reading →

Out-of-thin-air (OOTA) values are a troubling theoretical problem, but thus far do not actually occur in practice. In the words of the Bard: “It is a tale told by an idiot, full of sound and fury, signifying nothing.” But what … Continue reading →

An address dependency involves a load whose return value directly or indirectly determines the address of a later load or store, which results in the earlier load being ordered before the later load or store. A data dependency involves a … Continue reading →

At the assembly language level on many weakly ordered architectures, a conditional branch acts as a very weak, very cheap, but very useful memory-barrier instruction. It orders any load whose return value feeds into the condition codes before all stores … Continue reading →

One way to reduce the number of occurrences of unsafe in Rust code in Linux is to push the unsafety down into atomic operations, memory barriers, and locking primitives, which are the topic of this post. But first, here are … Continue reading →

At first glance, Rust’s concurrency philosophy resembles that of Sequent’s DYNIX and DYNIX/ptx in the 1980s and early 1990s: “Lock data, not code” (see Jack Inman’s classic USENIX’85 paper “Implementing Loosely Coupled Functions on Tightly Coupled Engines”, sadly invisible to … Continue reading →