Re: [PATCH v2 3/5] rust: percpu: add a rust per-CPU variable test

[Mitchell Levy <levymitchell0@gmail.com>]

On Sun, Jul 13, 2025 at 11:30:31AM +0200, Benno Lossin wrote:
> On Sat Jul 12, 2025 at 11:31 PM CEST, Mitchell Levy wrote:
> > Add a short exercise for Rust's per-CPU variable API, modelled after
> > lib/percpu_test.c
> >
> > Signed-off-by: Mitchell Levy <levymitchell0@gmail.com>
> > ---
> >  lib/Kconfig.debug       |   9 ++++
> >  lib/Makefile            |   1 +
> >  lib/percpu_test_rust.rs | 120 ++++++++++++++++++++++++++++++++++++++++++++++++
> 
> I don't know if this is the correct place, the code looks much more like
> a sample, so why not place it there instead?

I don't feel particularly strongly either way --- I defaulted to `lib/`
since that's where the `percpu_test.c` I was working off of is located.
Happy to change for v3

> >  rust/helpers/percpu.c   |  11 +++++
> >  4 files changed, 141 insertions(+)
> > diff --git a/lib/percpu_test_rust.rs b/lib/percpu_test_rust.rs
> > new file mode 100644
> > index 000000000000..a9652e6ece08
> > --- /dev/null
> > +++ b/lib/percpu_test_rust.rs
> > @@ -0,0 +1,120 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +//! A simple self test for the rust per-CPU API.
> > +
> > +use core::ffi::c_void;
> > +
> > +use kernel::{
> > +    bindings::{on_each_cpu, smp_processor_id},
> > +    define_per_cpu,
> > +    percpu::{cpu_guard::*, *},
> > +    pr_info,
> > +    prelude::*,
> > +    unsafe_get_per_cpu,
> > +};
> > +
> > +module! {
> > +    type: PerCpuTestModule,
> > +    name: "percpu_test_rust",
> > +    author: "Mitchell Levy",
> > +    description: "Test code to exercise the Rust Per CPU variable API",
> > +    license: "GPL v2",
> > +}
> > +
> > +struct PerCpuTestModule;
> > +
> > +define_per_cpu!(PERCPU: i64 = 0);
> > +define_per_cpu!(UPERCPU: u64 = 0);
> > +
> > +impl kernel::Module for PerCpuTestModule {
> > +    fn init(_module: &'static ThisModule) -> Result<Self, Error> {
> > +        pr_info!("rust percpu test start\n");
> > +
> > +        let mut native: i64 = 0;
> > +        // SAFETY: PERCPU is properly defined
> > +        let mut pcpu: StaticPerCpu<i64> = unsafe { unsafe_get_per_cpu!(PERCPU) };
> 
> I don't understand why we need unsafe here, can't we just create
> something specially in the `define_per_cpu` macro that is then confirmed
> by the `get_per_cpu!` macro and thus it can be safe?

As is, something like
    define_per_cpu!(PERCPU: i32 = 0);

    fn func() {
        let mut pcpu: StaticPerCpu<i64> = unsafe { unsafe_get_per_cpu!(PERCPU) };
    }
will compile, but any usage of `pcpu` will be UB. This is because
`unsafe_get_per_cpu!` is just blindly casting pointers and, as far as I
know, the compiler does not do any checking of pointer casts. If you
have thoughts/ideas on how to get around this problem, I'd certainly
*like* to provide a safe API here :)

> > +        // SAFETY: We only have one PerCpu that points at PERCPU
> > +        unsafe { pcpu.get(CpuGuard::new()) }.with(|val: &mut i64| {
> 
> Hmm I also don't like the unsafe part here...
> 
> Can't we use the same API that `thread_local!` in the standard library
> has:
> 
>     https://doc.rust-lang.org/std/macro.thread_local.html
> 
> So in this example you would store a `Cell<i64>` instead.
> 
> I'm not familiar with per CPU variables, but if you're usually storing
> `Copy` types, then this is much better wrt not having unsafe code
> everywhere.
> 
> If one also often stores `!Copy` types, then we might be able to get
> away with `RefCell`, but that's a small runtime overhead -- which is
> probably bad given that per cpu variables are most likely used for
> performance reasons? In that case the user might just need to store
> `UnsafeCell` and use unsafe regardless. (or we invent something
> specifically for that case, eg tokens that are statically known to be
> unique etc)

I'm open to including a specialization for `T: Copy` in a similar vein
to what I have here for numeric types. Off the top of my head, that
shouldn't require any user-facing `unsafe`. But yes, I believe there is
a significant amount of interest in having `!Copy` per-CPU variables.
(At least, I'm interested in having them around for experimenting with
using Rust for HV drivers.)

I would definitely like to avoid *requiring* the use of `RefCell` since,
as you mention, it does have a runtime overhead. Per-CPU variables can
be used for "logical" reasons rather than just as a performance
optimization, so there might be some cases where paying the runtime
overhead is ok. But that's certainly not true in all cases. That said,
perhaps there could be a safely obtainable token type that only passes a
`&T` (rather than a `&mut T`) to its closure, and then if a user doesn't
mind the runtime overhead, they can choose `T` to be a `RefCell`.
Thoughts?

For `UnsafeCell`, if a user of the API were to have something like a
`PerCpu<UnsafeCell<T>>` that safely spits out a `&UnsafeCell<T>`, my
understanding is that mutating the underlying `T` would require the
exact same safety guarantees as what's here, except now it'd need a much
bigger unsafe block and would have to do all of its manipulations via
pointers. That seems like a pretty big ergonomics burden without a clear
(to me) benefit.

> ---
> Cheers,
> Benno
> 
> > +            pr_info!("The contents of pcpu are {}\n", val);
> > +
> > +            native += -1;
> > +            *val += -1;
> > +            pr_info!("Native: {}, *pcpu: {}\n", native, val);
> > +            assert!(native == *val && native == -1);
> > +
> > +            native += 1;
> > +            *val += 1;
> > +            pr_info!("Native: {}, *pcpu: {}\n", native, val);
> > +            assert!(native == *val && native == 0);
> > +        });