[PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage

Marco Crivellari posted 2 patches 1 week, 2 days ago
include/linux/workqueue.h |  1 +
kernel/workqueue.c        | 31 ++++++++++++++++++++++++++++---
2 files changed, 29 insertions(+), 3 deletions(-)
[PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
Posted by Marco Crivellari 1 week, 2 days ago
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. The detection of
deprecated workqueue is done using a new internal flag, called __WQ_DEPRECATED.

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, WARN_ONCE() is used.

Thanks!


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

 include/linux/workqueue.h |  1 +
 kernel/workqueue.c        | 31 ++++++++++++++++++++++++++++---
 2 files changed, 29 insertions(+), 3 deletions(-)

---
Changes in v4:
- P2: instead of pr_warn_once() use WARN_ONCE()

Link to v3: https://lore.kernel.org/all/20260528160159.471265-1-marco.crivellari@suse.com/

Changes in v3:
- system_wq / system_unbond_wq not routed to the newer. The warnings have been simpliified
  keeping only one of them inside __queue_work() printing the work function.

- the deprecated status is detected using a new internal flag, called __WQ_DEPRECATED.

Link to v2: https://lore.kernel.org/all/20260526150041.365392-1-marco.crivellari@suse.com/

Changes in v2:
- rebased on v7.1-rc5

- fixed typo in the text

- cleared WQ_PERCPU when wq_pwer_efficient flag is set, to avoid triggering a warning

- if statement to route old workqueue to newer also added in queue_rcu_work()

Link to v1: https://lore.kernel.org/all/20260514092354.125149-1-marco.crivellari@suse.com/

-- 
2.54.0
Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
Posted by Tejun Heo 1 week, 2 days ago
Hello,

On Fri, May 29, 2026 at 03:06:38PM +0200, Marco Crivellari wrote:
> Marco Crivellari (2):
>   workqueue: Add warnings and fallback if system_{unbound}_wq is used
>   workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND
>     is present

Applied 1-2 to wq/for-7.2. I fixed up minor whitespace on 2/2: added the
missing space in "else if (" and dropped the redundant parentheses around
~WQ_PERCPU.

Thanks.

-- 
tejun
Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
Posted by Marco Crivellari 6 days, 19 hours ago
On Fri, May 29, 2026 at 8:07 PM Tejun Heo <tj@kernel.org> wrote:
>
> Hello,
>
> On Fri, May 29, 2026 at 03:06:38PM +0200, Marco Crivellari wrote:
> > Marco Crivellari (2):
> >   workqueue: Add warnings and fallback if system_{unbound}_wq is used
> >   workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND
> >     is present
>
> Applied 1-2 to wq/for-7.2. I fixed up minor whitespace on 2/2: added the
> missing space in "else if (" and dropped the redundant parentheses around
> ~WQ_PERCPU.

Hello Tejun,

Many thanks!

-- 

Marco Crivellari

SUSE Labs
Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
Posted by Tetsuo Handa 1 week, 2 days ago
On 2026/05/30 3:07, Tejun Heo wrote:
> Hello,
> 
> On Fri, May 29, 2026 at 03:06:38PM +0200, Marco Crivellari wrote:
>> Marco Crivellari (2):
>>   workqueue: Add warnings and fallback if system_{unbound}_wq is used
>>   workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND
>>     is present
> 
> Applied 1-2 to wq/for-7.2. I fixed up minor whitespace on 2/2: added the
> missing space in "else if (" and dropped the redundant parentheses around
> ~WQ_PERCPU.

Please don't use WARN_ONCE(), please use printk() but don't emit WARNING: or BUG: in the string.
syzbot is failing to test linux-next kernels due to commit 21c05ca88a54 ("workqueue:
Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present").
We can't tolerate linux-next being untested until all callers are fixed.
Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
Posted by Tejun Heo 1 week ago
Sorry for the slow reply - I'm off at the moment so my latency is high.

> syzbot is failing to test linux-next kernels due to commit 21c05ca88a54
> ("workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is
> present").
> We can't tolerate linux-next being untested until all callers are fixed.

Which caller is breaking which tests?

Reverting 21c05ca88a54 is easy, but there's no clean point to do it: the
warning is in the wq tree while the caller fixes are scattered across several
subsystem trees, and there's no reasonable way to synchronize all of that
outside mainline. If it's a specific caller breaking a test, fixing that one
is the better path.

Thanks.
Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
Posted by Tetsuo Handa 1 week ago
On 2026/06/01 1:48, Tejun Heo wrote:
> Sorry for the slow reply - I'm off at the moment so my latency is high.
> 
>> syzbot is failing to test linux-next kernels due to commit 21c05ca88a54
>> ("workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is
>> present").
>> We can't tolerate linux-next being untested until all callers are fixed.
> 
> Which caller is breaking which tests?

It is https://syzkaller.appspot.com/bug?extid=d078cba4418e65f61984 .

Even 10 days of being unable to test linux-next tree
( https://lkml.kernel.org/r/1a9f53d4-6f48-4df8-a3d8-2b0e442a163a@I-love.SAKURA.ne.jp )
can cause difficulty of identifying a culprit.

> 
> Reverting 21c05ca88a54 is easy, but there's no clean point to do it: the
> warning is in the wq tree while the caller fixes are scattered across several
> subsystem trees, and there's no reasonable way to synchronize all of that
> outside mainline. If it's a specific caller breaking a test, fixing that one
> is the better path.
> 

I've spent more than one year for updating all in-tree users who are
flushing kernel global workqueues. Please see a message from Linus at
https://lkml.kernel.org/r/CAHk-=whWreGjEQ6yasspzBrNnS7EQiL+SknToWt=SzUh4XomyQ@mail.gmail.com .

Please never try to emit WARNING: or BUG: message just for letting developers
update their code. If you can't use panic() instead of WARN*() or BUG*(), you
should not use WARN*() or BUG*(). The patch author who changes the behavior of
in-tree code is responsible for updating all in-tree code.
Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
Posted by Tejun Heo 6 days, 20 hours ago
On Mon, Jun 01, 2026 at 07:12:28AM +0900, Tetsuo Handa wrote:
> I've spent more than one year for updating all in-tree users who are
> flushing kernel global workqueues. Please see a message from Linus at
> https://lkml.kernel.org/r/CAHk-=whWreGjEQ6yasspzBrNnS7EQiL+SknToWt=SzUh4XomyQ@mail.gmail.com .
> 
> Please never try to emit WARNING: or BUG: message just for letting developers
> update their code. If you can't use panic() instead of WARN*() or BUG*(), you
> should not use WARN*() or BUG*(). The patch author who changes the behavior of
> in-tree code is responsible for updating all in-tree code.

I don't think a statement this blanket makes sense. I scanned the existing
linux-next tree and there were a handful that were missed (I didn't find out
whether they are new ones in linux-next or ones that were misseds from
mainline tho). Let's just apply the nvme-tcp patch and move on.

Thanks.

-- 
tejun
Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage
Posted by Tetsuo Handa 6 days, 17 hours ago
On 2026/06/01 23:47, Tejun Heo wrote:
> On Mon, Jun 01, 2026 at 07:12:28AM +0900, Tetsuo Handa wrote:
>> I've spent more than one year for updating all in-tree users who are
>> flushing kernel global workqueues. Please see a message from Linus at
>> https://lkml.kernel.org/r/CAHk-=whWreGjEQ6yasspzBrNnS7EQiL+SknToWt=SzUh4XomyQ@mail.gmail.com .
>>
>> Please never try to emit WARNING: or BUG: message just for letting developers
>> update their code. If you can't use panic() instead of WARN*() or BUG*(), you
>> should not use WARN*() or BUG*(). The patch author who changes the behavior of
>> in-tree code is responsible for updating all in-tree code.
> 
> I don't think a statement this blanket makes sense. I scanned the existing
> linux-next tree and there were a handful that were missed (I didn't find out
> whether they are new ones in linux-next or ones that were misseds from
> mainline tho). Let's just apply the nvme-tcp patch and move on.

Not all users are quickly accepting patches. Please apply all fixes *before* you start
emitting WARNING: message. You are currently making linux-next tree untestable by syzbot.

> 
> Thanks.
> 

Mark Brown, please skip WQ changes from linux-next until all fixes are applied.

Linus, please be sure to skip WQ changes in the upcoming merge window if some fix
does not get applied in time for the merge window. (Of course, applying all fixes
before we start emitting WARNING: message is desirable for bisectability, even if
all fixes are get applied in time for the merge window...)