Speaker
Description
The kernel's dma_fence subsystem lays at the heart of every graphics processing unit (GPU) driver. It is a primitive for synchronizing the state of jobs running on GPUs with receiver parties, notably userspace. A number of circumstances make the correct implementation and usage of both C and Rust dma_fence very challenging:
- The highly asynchronous nature of GPUs, including the fact that they can hang and need to be reset.
- The fact that fences can have an arbitrary number of consumers, both in other drivers and in userspace.
- Various, partially optional, callbacks exist, with which a consumer can run into the code of a producer, whose module might unload at any time.
Since GPUs can directly access system memory, an incorrect or racing representation of GPU job state by DmaFence could result in memory corruption regardless of Rust's memory safety guarantees.
Moreover, dma_fences have so far not only been involved in various UAF and refcounting bugs, but are also often involved in deadlock conditions. While making memory bugs impossible was the primary design goal for the Rust abstractions, much attention was also paid to preventing deadlock.
In 2026, a shared design, development and upstreaming effort by various parties, notably the Nova and Tyr GPU drivers, has seen much progress. This talk shall give an overview over the general design, solved and persisting problems, and special challenges with Rust regarding these abstractions.