Re: [PATCH v3 5/7] rust: percpu: Support non-zeroable types for DynamicPerCpu

[Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>]

On Thu, Aug 28, 2025 at 9:01 PM Mitchell Levy <levymitchell0@gmail.com> wrote:
>
> +    /// Get a `*mut MaybeUninit<T>` to the per-CPU variable on the CPU represented by `cpu`. Note
> +    /// that without some kind of synchronization, use of the returned pointer may cause a data
> +    /// race. It is the caller's responsibility to use the returned pointer in a reasonable way.

Please try to make the first paragraph ("short description" / title) smaller.

Does "reasonable" mean anything different than any other raw pointer?

> +    /// # Safety

Newline after section headers (also elsewhere).

> +    /// - The returned pointer is valid only if `self` is (that is, it points to a live allocation
> +    ///   correctly sized and aligned to hold a `T`)
> +    /// - The returned pointer is valid only if the bit corresponding to `cpu` is set in
> +    ///   `Cpumask::possible()`.

It sounds like the returned pointer can be invalid without triggering
UB -- could you please clarify why the method is `unsafe`?

In addition, please use intra-doc links wherever possible (e.g. there
a was also an `Arc` elsewhere).

> +        // SAFETY: The requirements of this function ensure this call is safe.
> +        unsafe { bindings::per_cpu_ptr(self.0.cast(), cpu.as_u32()) }.cast()

Please try to explain why, not just that it is. It isn't clear how the
safety preconditions, which only seem to talk about the returned
pointer, make this OK.

Thanks!

Cheers,
Miguel