Re: [PATCH v3 2/2] rust: workqueue: add creation of workqueues

[Alice Ryhl <aliceryhl@google.com>]

On Fri, Feb 27, 2026 at 08:23:44PM +0100, Danilo Krummrich wrote:
> On Fri Feb 27, 2026 at 8:05 PM CET, Alice Ryhl wrote:
> > On Fri, Feb 27, 2026 at 04:30:59PM +0100, Danilo Krummrich wrote:
> >> On Fri Feb 27, 2026 at 3:53 PM CET, Alice Ryhl wrote:
> >> > +    #[inline]
> >> > +    pub fn max_active(mut self, max_active: u32) -> Builder {
> >> > +        self.max_active = i32::try_from(max_active).unwrap_or(i32::MAX);
> >> 
> >> The workqueue code prints a warning for max_active >  WQ_MAX_ACTIVE. Maybe use
> >> debug_assert()?
> >
> > What's wrong with just making use of the C-side warning?
> 
> IIRC, we have the same pattern in other Rust code that we use debug_assert()
> when a value got clamped, e.g. in udelay().

In udelay(), the clamping happens on the Rust side, so it makes sense
that Rust is the one to warn about it.

Here, the clamping happens in C code. To warn about it, I'd have to
duplicate the existing C-side check to clamp in Rust.

> >> It's also a bit unfortunate that alloc_ordered_workqueue() becomes
> >> .max_active(1).
> >> 
> >> At the same time having a separate ordered() method competes with max_active().
> >> 
> >> Mybe a type state, i.e. Builder<Ordered> that doesn't have max_active()?
> >
> > Sorry I'm a bit confused by this. Why does an ordered() compete with
> > max_active()?
> 
> Because you could get an inconsistent state with __WQ_ORDERED and
> max_active > 1.
> 
> It also conflicts with sysfs() I think [1].
> 
> [1] https://elixir.bootlin.com/linux/v6.19.3/source/kernel/workqueue.c#L7417

And I guess the further argument is that we have a use-case for ordered
workqueues?

Alice