[RFC,v2,0/3] rust: Add Per-CPU Variable API

Message

Mitchell Levy April 14, 2025, 7:28 p.m. UTC

This series adds an API for declaring an using per-CPU variables from
Rust, and it also adds support for Rust access to C per-CPU variables
(subject to some soundness requirements). It also adds a small test
module, lib/percpu_test_rust.rs, in the vein of lib/percpu_test.c.

---
This series builds on my earlier RFC by adding support for dynamically
allocated per-CPU variables. In the process of this work, I became
convinced that the API in the original RFC was untenable. In particular,
copying a PerCpuRef would need to be an unsafe operation whose safety
requirements would be very onerous to verify. Essentially, a PerCpuRef
would need to be entirely unique on each CPU core (except for the moment
the copy is created, immediately before it is sent off to another thread
--- technically the requirement is that the copy could not be Deref'd
before being sent). This is essentially impossible to satisfy if you
wish to use on_each_cpu, and it is certainly not ergonomic.

The key challenge was preventing the creation of aliasing &mut T's while
still allowing PerCpu<T>'s to be freely copied. Ultimately, Boqun
suggested a closure-based API in which the user asserts that the
contents of the closure don't "nest" with clones. That is, the user
asserts that they're *not* doing something like:
```
let mut my_pcpu: PerCpu<u32> = /* ... */;
let mut my_pcpu2: PerCpu<u32> = my_pcpu.clone();
unsafe { my_pcpu.get(CpuGuard::new()) }.with(|my_pcpu_val: &mut u32| {
    // UNSAFETY: This is bad
    unsafe { my_pcpu2.get(CpuGuard::new()) }
      .with(|aliasing_ref: &mut u32| { /* ... */ });
}
```
This safety condition is (in my opinion) much easier to verify because
we must only ensure the contents of the closure are well-behaved, rather
than try and trace all possible paths that a PerCpuRef may take.

This API is certainly different from the original RFC, which is why I've
sent another RFC. It's now much closer to the user-space thread-local
API, though still avoids requiring the use of Cell-like types.

A small number of simplifying choices are made here, namely that
allocations are always GFP_KERNEL. This was done with the intention of
keeping the patch small while the overall shape of the API is evaluated.

Signed-off-by: Mitchell Levy <[e-mail]>

---
Changes from RFC:
- Renamed PerCpuVariable to StaticPerCpuSymbol to be more descriptive
- Support dynamically allocated per-CPU variables via the
  PerCpuAllocation type. Rework statically allocated variables to use
  this new type.
- Make use of a token/closure-based API via the PerCpu and PerCpuToken
  types, rather than an API based on PerCpuRef that automatically
  Deref(Mut)'s into a &(mut) T.
- Rebased
- Link to RFC: https://lore.kernel.org/r/[e-mail]

---
Mitchell Levy (3):
      rust: percpu: introduce a rust API for per-CPU variables
      rust: rust-analyzer: add lib to dirs searched for crates
      rust: percpu: add a rust per-CPU variable test

 lib/Kconfig.debug                 |   9 ++
 lib/Makefile                      |   1 +
 lib/percpu_test_rust.rs           | 119 +++++++++++++++++++
 rust/helpers/helpers.c            |   2 +
 rust/helpers/percpu.c             |  20 ++++
 rust/helpers/preempt.c            |  14 +++
 rust/kernel/lib.rs                |   3 +
 rust/kernel/percpu.rs             | 239 ++++++++++++++++++++++++++++++++++++++
 rust/kernel/percpu/cpu_guard.rs   |  29 +++++
 scripts/generate_rust_analyzer.py |   2 +-
 10 files changed, 437 insertions(+), 1 deletion(-)
---
base-commit: a2cc6ff5ec8f91bc463fd3b0c26b61166a07eb11
change-id: 20240813-rust-percpu-ea2f54b5da33

Best regards,