linux-kernel - Re: [RFC PATCH] rust: workqueue: Add an example for try

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 for Android: free password hash cracker in your pocket

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

Message-ID: <aIp0uo5y9O551HW9@tardis-2.local>
Date: Wed, 30 Jul 2025 12:38:34 -0700
From: Boqun Feng <boqun.feng@...il.com>
To: Benno Lossin <lossin@...nel.org>
Cc: rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
	Miguel Ojeda <ojeda@...nel.org>,
	Alex Gaynor <alex.gaynor@...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>,
	Danilo Krummrich <dakr@...nel.org>, Tejun Heo <tj@...nel.org>,
	Tamir Duberstein <tamird@...il.com>,
	Hamza Mahfooz <hamzamahfooz@...ux.microsoft.com>,
	Alban Kurti <kurti@...icto.ai>,
	Joel Fernandes <joelagnelf@...dia.com>,
	"Paul E. McKenney" <paulmck@...nel.org>
Subject: Re: [RFC PATCH] rust: workqueue: Add an example for try_spawn()

On Wed, Jul 30, 2025 at 09:28:05PM +0200, Benno Lossin wrote:
> On Wed Jul 30, 2025 at 6:34 PM CEST, Boqun Feng wrote:
> > `try_spawn()` could use an example to demonstrate the usage, and
> > arguably it's the most simple usage of workqueue in case someone needs a
> > deferred work, so add it.
> >
> > Cc: Joel Fernandes <joelagnelf@...dia.com>
> > Cc: "Paul E. McKenney" <paulmck@...nel.org>
> > Signed-off-by: Boqun Feng <boqun.feng@...il.com>
> > ---
> > Miguel, Alice and Tejun, while I'm at it, should we also rename the
> > function to `spawn()` because of the motivation mentioned here [1]?
> >
> > [1]: https://rust-for-linux.zulipchat.com/#narrow/channel/291566-Library/topic/.60new.60.20or.20.60try_new.60.3F/near/529533317
> >
> > Also I find the `{ <clone> || { } }` is really good if I only need to
> > clone the Arc for passing to a callback closure, but I'm not sure how
> > people feel about it, so criticism is welcome ;-)
> 
> I'm not so sure, see below :)
> 
> >  rust/kernel/workqueue.rs | 27 +++++++++++++++++++++++++++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/rust/kernel/workqueue.rs b/rust/kernel/workqueue.rs
> > index b9343d5bc00f..59c1a5e14d12 100644
> > --- a/rust/kernel/workqueue.rs
> > +++ b/rust/kernel/workqueue.rs
> > @@ -331,6 +331,33 @@ pub fn enqueue_delayed<W, const ID: u64>(&self, w: W, delay: Jiffies) -> W::Enqu
> >      /// Tries to spawn the given function or closure as a work item.
> >      ///
> >      /// This method can fail because it allocates memory to store the work item.
> > +    ///
> > +    /// # Examples
> > +    ///
> > +    /// ```
> > +    /// use kernel::{alloc::flags, sync::{Arc, Completion, new_spinlock}, workqueue};
> > +    ///
> > +    /// let work_done = Arc::pin_init(Completion::new(), flags::GFP_KERNEL)?;
> > +    /// let data = Arc::pin_init(new_spinlock!(0), flags::GFP_KERNEL)?;
> > +    ///
> > +    /// workqueue::system().try_spawn(
> > +    ///     flags::GFP_KERNEL,
> > +    ///     {
> > +    ///         let work_done = work_done.clone();
> > +    ///         let data = data.clone();
> > +    ///         move || {
> > +    ///             *data.lock() = 42;
> > +    ///             work_done.complete_all();
> > +    ///         }
> > +    ///     }
> > +    /// )?;
> 
> Not doing your pattern and instead adding a `2` postfix we get:
> 
>     let work_done2 = work_done.clone();
>     let data2 = data.clone();
> 

Yeah, the thing I want to achieve with my pattern is: make it clear that
the work and the task that queues the work are sharing the same
`work_done` and `data` (well, no the same `Arc` exactly, but the `Arc`s
that are pointing to the same object). This pattern here doesn't show
that clearly imo.

That said, I'm not really against using `work_done2` and `data2`, just
I'm afraid that may be more confusing.

>     workqueue::system().try_spawn(flags::GFP_KERNEL, move || {
>         *data2.lock() = 42;
>         work_done2.complete_all();
>     })?;
> 
> There are some discussions of introducing some better syntax for (cheap)
> cloning, so maybe we can use that in the future.

Do you have links to these discussions.

Regards,
Boqun

> 
> ---
> Cheers,
> Benno
> 
> > +    ///
> > +    /// work_done.wait_for_completion();
> > +    ///
> > +    /// // `work_done` being completed implies the observation of the write of `data` in the work.
> > +    /// assert_eq!(*data.lock(), 42);
> > +    /// # Ok::<(), Error>(())
> > +    /// ```
> >      pub fn try_spawn<T: 'static + Send + FnOnce()>(
> >          &self,
> >          flags: Flags,
>