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