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: <68b9ff1c.050a0220.35de1d.11b7@mx.google.com>
Date: Thu, 4 Sep 2025 14:05:29 -0700
From: Mitchell Levy <levymitchell0@...il.com>
To: Yury Norov <yury.norov@...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>,
	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, Sep 04, 2025 at 04:37:02PM -0400, Yury Norov wrote:
> On Thu, Sep 04, 2025 at 01:26:07PM -0700, Mitchell Levy wrote:
> > On Wed, Sep 03, 2025 at 06:19:25PM -0400, Yury Norov wrote:
> > > On Thu, Aug 28, 2025 at 12:00:12PM -0700, Mitchell Levy wrote:
> 
> ...
> 
> > > > +impl<T: Clone> DynamicPerCpu<T> {
> > > > +    /// Allocates a new per-CPU variable
> > > > +    ///
> > > > +    /// # Arguments
> > > > +    /// * `val` - The initial value of the per-CPU variable on all CPUs.
> > > > +    /// * `flags` - Flags used to allocate an `Arc` that keeps track of the underlying
> > > > +    ///   `PerCpuAllocation`.
> > > > +    pub fn new_with(val: T, flags: Flags) -> Option<Self> {
> > > > +        let alloc: PerCpuAllocation<T> = PerCpuAllocation::new_uninit()?;
> > > > +        let ptr = alloc.0;
> > > > +
> > > > +        for cpu in Cpumask::possible().iter() {
> > > 
> > > In C we've got the 'for_each_possible_cpu()'. Is there any way to
> > > preserve that semantics in rust? I really believe that similar
> > > semantics on higher level on both sides will help _a_lot_ for those
> > > transitioning into the rust world (like me).
> > 
> > I'm not sure I understand what you mean --- I believe the semantics
> > should be the same here (`cpu` takes on each value in
> > `cpu_possible_mask`). Could you please clarify?
> > 
> 
> I mean:
> 
>         for_each_possible_cpu(cpu) {
>                 let remote_ptr = unsafe { ptr.get_remote_ptr(cpu) };
>                 unsafe { (*remote_ptr).write(val.clone()); }
>                 let arc = Arc::new(alloc, flags).ok()?;
>                 Some(Self { alloc: arc })
>         }
> 
> Is it possible to do the above in rust?

Ah, I see.

The syntax would be slightly different, probably something like

        use cpu::for_each_possible_cpu;

        for_each_possible_cpu(|&cpu| {
                let remote_ptr = unsafe { ptr.get_remote_ptr(cpu) };
                // ...
        })

it *might* also be possible to use a macro and dispense with the need for
a closure, though I'm not familiar enough with proc macros to say for
sure. That would probably look like

        for_each_possible_cpu!(cpu) {
                let remote_ptr = unsafe { ptr.get_remote_ptr(cpu) };
                // ...
        }

though personally I think the first one is better (simpler
implementation without too much syntactic overhead, especially since
closures are already used some within R4L).

Thanks,
Mitchell