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

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

[Tetsuo Handa]

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...)

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

[Tetsuo Handa]

On 2026/06/02 2:51, Tetsuo Handa wrote:
> 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...)
> 

After 10 days of untestable period, the third breakage report came from btrfs
caused by commit 69635d7f4b34 ("fs: WQ_PERCPU added to alloc_workqueue users").
That commit added WQ_PERCPU to fs/btrfs/disk-io.c despite the "ordered_flags" is
passed to alloc_ordered_workqueue() which implicitly applies WQ_UNBOUND.

That commit says

  Both flags coexist for one release cycle to allow callers to transition
  their calls.

  Once migration is complete, WQ_UNBOUND can be removed and unbound will
  become the implicit default.

and you definitely started emitting WARNING: messages before allowing callers
to transition their calls. I consider that commit 21c05ca88a54 ("workqueue: Add
warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present") should be
excluded from the linux-next and the upcoming merge window. The next one or two
cycles for transition should be printk() without WARNING: string.

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 1244 bytes --]

On Wed, Jun 10, 2026 at 09:48:05PM +0900, Tetsuo Handa wrote:
> On 2026/06/02 2:51, Tetsuo Handa wrote:
> > On 2026/06/01 23:47, Tejun Heo wrote:

> > 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.

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

So that's the workqueues tree so extra disruption would be limited but TBH
as far as kicking things out goes I'd be more inclined to take a steer
from Linus on his thinking here rather than making that decision for
myself, especially this close to the merge window.  If there's changes
that can't be applied directly to the workqueues tree one thing I could
do that's a bit less disruptive is carry those fixups in -next, do the
appropriate patches exist?  We'd obviously need to make sure they get
into mainline promptly.

Just as a note here if you put something at the top of the mail when you
add me it increases my chances of seeing the bit directed at me - I get
CCed on a *lot* of mail that's not at all relevant to me, unfortunately
that means I'm a bit lossy when it comes to triaging my inbox.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Nathan Chancellor]

On Wed, Jun 10, 2026 at 09:48:05PM +0900, Tetsuo Handa wrote:
> After 10 days of untestable period, the third breakage report came from btrfs
> caused by commit 69635d7f4b34 ("fs: WQ_PERCPU added to alloc_workqueue users").
> That commit added WQ_PERCPU to fs/btrfs/disk-io.c despite the "ordered_flags" is
> passed to alloc_ordered_workqueue() which implicitly applies WQ_UNBOUND.
> 
> That commit says
> 
>   Both flags coexist for one release cycle to allow callers to transition
>   their calls.
> 
>   Once migration is complete, WQ_UNBOUND can be removed and unbound will
>   become the implicit default.
> 
> and you definitely started emitting WARNING: messages before allowing callers
> to transition their calls. I consider that commit 21c05ca88a54 ("workqueue: Add
> warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present") should be
> excluded from the linux-next and the upcoming merge window. The next one or two
> cycles for transition should be printk() without WARNING: string.

FWIW, I sent a patch for the btrfs issue:

  https://lore.kernel.org/20260601-btrfs-fix-wq-warning-qgroup-rescan-v1-1-aff9a1128f27@kernel.org/

With that applied to next-20260610, I don't see any other instances of
this workqueue warning on any of my test machines. I do agree that
enabling warnings prematurely is disruptive for testing and should be
avoided but it seems like this one is close? That change should be
applicable to the workqueue tree, it just needs to be taken at this
point.

-- 
Cheers,
Nathan