linux-kernel - Re: [PATCH v2 2/2] rust: workqueue: add creation of workqueues

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: <aRY28VITGL53zenZ@tardis.local>
Date: Thu, 13 Nov 2025 11:52:17 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Alice Ryhl <aliceryhl@...gle.com>
Cc: Tejun Heo <tj@...nel.org>, Miguel Ojeda <ojeda@...nel.org>,
	Lai Jiangshan <jiangshanlai@...il.com>, Gary Guo <gary@...yguo.net>,
	Björn Roy Baron <bjorn3_gh@...tonmail.com>,
	Andreas Hindborg <a.hindborg@...nel.org>,
	Trevor Gross <tmgross@...ch.edu>,
	Danilo Krummrich <dakr@...nel.org>,
	Daniel Almeida <daniel.almeida@...labora.com>,
	John Hubbard <jhubbard@...dia.com>,
	Philipp Stanner <phasta@...nel.org>,
	Tamir Duberstein <tamird@...il.com>, rust-for-linux@...r.kernel.org,
	linux-kernel@...r.kernel.org, Benno Lossin <lossin@...nel.org>
Subject: Re: [PATCH v2 2/2] rust: workqueue: add creation of workqueues

On Thu, Nov 13, 2025 at 10:01:07AM +0000, Alice Ryhl wrote:
> Creating workqueues is needed by various GPU drivers. Not only does it
> give you better control over execution, it also allows devices to ensure
> that all tasks have exited before the device is unbound (or similar) by
> running the workqueue destructor.
> 
> A wrapper type Flags is provided for workqueue flags. It allows you to
> build any valid flag combination, while using a type-level marker for
> whether WQ_BH is used to prevent invalid flag combinations. The Flags wrapper
> also forces you to explicitly pick one of percpu, unbound, or bh.
> 
> Signed-off-by: Alice Ryhl <aliceryhl@...gle.com>
[...]
> +/// An owned kernel work queue.
> +///
> +/// Dropping a workqueue blocks on all pending work.
> +///
> +/// # Invariants
> +///
> +/// `queue` points at a valid workqueue that is owned by this `OwnedQueue`.
> +pub struct OwnedQueue {
> +    queue: NonNull<Queue>,

I hope Owned/Ownable can make it just a Owned<Queue> here ;-) And
that'll make Owned<Queue> automatically Send + Sync. I think it's not a
rare ask for `OwnedQueue` to be Send + Sync.

> +}
> +
> +#[expect(clippy::manual_c_str_literals)]
> +impl OwnedQueue {
> +    /// Allocates a new workqueue.
> +    ///
> +    /// The provided name is used verbatim as the workqueue name.
> +    ///
> +    /// # Examples
> +    ///
> +    /// ```
> +    /// use kernel::c_str;
> +    /// use kernel::workqueue::{OwnedQueue, Flags};
> +    ///
> +    /// let wq = OwnedQueue::new(c_str!("my-wq"), Flags::unbound().sysfs(), 0)?;
> +    /// wq.try_spawn(
> +    ///     GFP_KERNEL,
> +    ///     || pr_warn!("Printing from my-wq"),
> +    /// )?;
> +    /// # Ok::<(), Error>(())
> +    /// ```
> +    #[inline]
> +    pub fn new<const BH: bool>(
> +        name: &CStr,
> +        flags: Flags<BH>,
> +        max_active: usize,

Do we need to support `max_active` as `usize` when the underlying C
code only support i32?

Regards,
Boqun

> +    ) -> Result<OwnedQueue, AllocError> {
> +        // SAFETY:
> +        // * "%s\0" is compatible with passing the name as a c-string.
> +        // * the flags argument does not include internal flags.
> +        let ptr = unsafe {
> +            bindings::alloc_workqueue(
> +                b"%s\0".as_ptr(),
> +                flags.0,
> +                i32::try_from(max_active).unwrap_or(i32::MAX),
> +                name.as_char_ptr().cast::<c_void>(),
> +            )
> +        };
> +
> +        Ok(OwnedQueue {
> +            queue: NonNull::new(ptr).ok_or(AllocError)?.cast(),
> +        })
> +    }
[...]