Hi,

Currently system_wq and system_unbound_wq can still be used and no message
is printed. To avoid further use of them, add a warning and route the
workqueue on system_percpu_wq or system_dfl_wq.

Similar scenario for WQ_PERCPU and WQ_UNBOUND. Currently there are still
users that use alloc_workqueue(,0,). To avoid such situations, a couple
of checks have been added:

  - if neither of the flag is present, set WQ_PERCPU
  - if both are present, remove WQ_PERCPU

Along with these, a warning will be printed.

~~~~

Few things to note, and that's the main reason because it is an RFC:

1. I wanted to use a compile time error, but considering the new users still
   relying on the old workqueue or using alloc_workqueue() without one of the
   flags, it means break the code. So I decided to avoid.

2. there are no compile-time warnings: should we add something?

3. __alloc_workqueue() prints the WQ_* messages with pr_warn_ratelimited();
   I used this because otherwise with the _once version we're going to see
   only the 1st.

4. another option would have been make the workqueue unbound by default, but
   of course, it's still not possible due to point 1.


Thanks!

Marco Crivellari (2):
  workqueue: Add warn and fallback if system_{unbound}_wq is used
  workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND
    is present

 kernel/workqueue.c | 72 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 72 insertions(+)

-- 
2.54.0

On Thu, May 14, 2026 at 11:23:52AM +0200, Marco Crivellari wrote:
> Hi,
> 
> Currently system_wq and system_unbound_wq can still be used and no message
> is printed. To avoid further use of them, add a warning and route the
> workqueue on system_percpu_wq or system_dfl_wq.
> 
> Similar scenario for WQ_PERCPU and WQ_UNBOUND. Currently there are still
> users that use alloc_workqueue(,0,). To avoid such situations, a couple
> of checks have been added:
> 
>   - if neither of the flag is present, set WQ_PERCPU
>   - if both are present, remove WQ_PERCPU
> 
> Along with these, a warning will be printed.

How many users will seee this warning once this patch lands?

On Fri, May 15, 2026 at 2:17 PM Breno Leitao <leitao@debian.org> wrote:
>
> On Thu, May 14, 2026 at 11:23:52AM +0200, Marco Crivellari wrote:
> > Hi,
> >
> > Currently system_wq and system_unbound_wq can still be used and no message
> > is printed. To avoid further use of them, add a warning and route the
> > workqueue on system_percpu_wq or system_dfl_wq.
> >
> > Similar scenario for WQ_PERCPU and WQ_UNBOUND. Currently there are still
> > users that use alloc_workqueue(,0,). To avoid such situations, a couple
> > of checks have been added:
> >
> >   - if neither of the flag is present, set WQ_PERCPU
> >   - if both are present, remove WQ_PERCPU
> >
> > Along with these, a warning will be printed.
>
> How many users will seee this warning once this patch lands?

About WQ_*, I would say (currently, v7.1-rc3) there are 8 users, but 4
of them are accepted (2 by Tejun, because we didn't receive replies
for a long time) and the other 2 will likely be accepted in May (they
are new and were sent a few days ago).

About the deprecated workqueues:

system_wq: 8 (-3, accepted, 1 handled by Tejun)
system_unbound_wq: 19

Among the 19, 2 are new (recently introduced and still pending
changes), and Tejun handles other two of them. Note that 7 of the
remaining 15 are part of the same series.

I think the most important change, because it is also a blocker, is
requiring alloc_workqueue() users to have one of the flags. This will
allow us to switch to the unbound workqueue as default, removing
`WQ_UNBOUND` as well. We cannot of course do that now.

What do you think?

Thanks!

-- 

Marco Crivellari

SUSE Labs