Description
Background: In Linux kernel, we have Linux Kernel Memory (Consistency) Model, or LKMM for short, which provides a set of atomic primitives and a (somewhat) formal model to describe their semantics. And there are couples of differences between LKMM and Rust's memory model. So when Rust comes into the picture of Linux kernel development, one thing we need to deal with is which memory model to use.
I'd like to propose that we have a place where we can document/track our current "policy" and any future plan for memory ordering models (including synchronization primitives and program-preserved ordering) used in Rust-for-Linux. Eventually, we will have in-kernel documentation for this, but let's use this issue to get things clarified in early stages.
I had a few discussions. And based on the discussions, below is the best option to start with in my opinion:
- Avoid using Rust atomics and memory ordering model (i.e. C11 memory ordering model).
- Implement barriers and LKMM atomics via
asm!or FFI, and in-kernel Rust code should use LKMM atomics and the model.
Couples of reasons here (I will provide some summary about the previous discussion in this issue in the form of comments as well):
- Dealing with two memory ordering models could introduce risks in both practice and theory, and most of people working on Linux kernel are already (or should be) familiar with Linux Kernel Memory Model.
- It's very likely a Rust driver would need to talk with a C component, having (and using) a Rust version of LKMM atomics is necessary in this case to avoid reasoning with two models.
- It's simple to just have one memory model to start with, and we can always re-evaluate as things move on.
I'm going to prepare a patchset to add initial documentation of the memory model policy and implementation of atomic APIs. Happy to hear any feedback, and tests and reviews in the future are welcome!