Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Memory ordering model policy/plan #1067

Open
fbq opened this issue Mar 6, 2024 · 2 comments
Open

Memory ordering model policy/plan #1067

fbq opened this issue Mar 6, 2024 · 2 comments
Assignees
Labels
meta Meta issue.

Comments

@fbq
Copy link
Member

fbq commented Mar 6, 2024

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!

@fbq fbq added the meta Meta issue. label Mar 6, 2024
@fbq fbq self-assigned this Mar 6, 2024
@fbq
Copy link
Member Author

fbq commented Mar 6, 2024

Here is the branch with some atomics implemented: https://github.com/fbq/linux/tree/dev/rust/atomic

@ojeda ojeda mentioned this issue Mar 6, 2024
37 tasks
@ojeda
Copy link
Member

ojeda commented Apr 6, 2024

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
meta Meta issue.
Development

No branches or pull requests

2 participants