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@xxxxxxxxxx/

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