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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CANiq72nnWmzOfZ1PhSid4t_e-yWEgi_hVx5Uj4hrB9wzpuP6nA@mail.gmail.com>
Date: Thu, 4 Sep 2025 01:05:36 +0200
From: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To: Mitchell Levy <levymitchell0@...il.com>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>, 
	Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>, 
	Björn Roy Baron <bjorn3_gh@...tonmail.com>, 
	Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>, 
	Trevor Gross <tmgross@...ch.edu>, Andrew Morton <akpm@...ux-foundation.org>, 
	Dennis Zhou <dennis@...nel.org>, Tejun Heo <tj@...nel.org>, Christoph Lameter <cl@...ux.com>, 
	Danilo Krummrich <dakr@...nel.org>, Benno Lossin <lossin@...nel.org>, Yury Norov <yury.norov@...il.com>, 
	Viresh Kumar <viresh.kumar@...aro.org>, Tyler Hicks <code@...icks.com>, linux-kernel@...r.kernel.org, 
	rust-for-linux@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH v3 5/7] rust: percpu: Support non-zeroable types for DynamicPerCpu

On Thu, Aug 28, 2025 at 9:01 PM Mitchell Levy <levymitchell0@...il.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