[PATCH] btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()

[PATCH] btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()

[Nathan Chancellor]

After commit 21c05ca88a54 ("workqueue: Add warnings and ensure one among
WQ_PERCPU or WQ_UNBOUND is present"), there is a warning from the
btrfs-qgroup-rescan workqueue at run time:

  workqueue: btrfs-qgroup-rescan uses both WQ_PERCPU and WQ_UNBOUND. Dropped WQ_PERCPU, keeping WQ_UNBOUND.

WQ_PERCPU is included in ordered_flags after commit 69635d7f4b34 ("fs:
WQ_PERCPU added to alloc_workqueue users") and WQ_UNBOUND is set in
alloc_ordered_workqueue(), which btrfs_alloc_ordered_workqueue() calls.

Drop WQ_PERCPU from ordered_flags, as alloc_ordered_workqueue() notes
that only WQ_FREEZABLE and WQ_MEM_RECLAIM are meaningful.

Fixes: 69635d7f4b34 ("fs: WQ_PERCPU added to alloc_workqueue users")
Fixes: 21c05ca88a54 ("workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
---
This should go in via the workqueue tree that adds the warning.
---
 fs/btrfs/disk-io.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index 8a11be02eeb9..f2a3b0705486 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -1928,7 +1928,7 @@ static int btrfs_init_workqueues(struct btrfs_fs_info *fs_info)
 {
 	u32 max_active = fs_info->thread_pool_size;
 	unsigned int flags = WQ_MEM_RECLAIM | WQ_FREEZABLE | WQ_UNBOUND;
-	unsigned int ordered_flags = WQ_MEM_RECLAIM | WQ_FREEZABLE | WQ_PERCPU;
+	unsigned int ordered_flags = WQ_MEM_RECLAIM | WQ_FREEZABLE;
 
 	fs_info->workers =
 		btrfs_alloc_workqueue(fs_info, "worker", flags, max_active, 16);

---
base-commit: 21c05ca88a548ca1353cbef189c97d4f03b90692
change-id: 20260601-btrfs-fix-wq-warning-qgroup-rescan-9451da1845fb

Best regards,
--  
Cheers,
Nathan

Re: [PATCH] btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()

[David Sterba]

On Mon, Jun 01, 2026 at 07:46:26PM -0700, Nathan Chancellor wrote:
> After commit 21c05ca88a54 ("workqueue: Add warnings and ensure one among
> WQ_PERCPU or WQ_UNBOUND is present"), there is a warning from the
> btrfs-qgroup-rescan workqueue at run time:
> 
>   workqueue: btrfs-qgroup-rescan uses both WQ_PERCPU and WQ_UNBOUND. Dropped WQ_PERCPU, keeping WQ_UNBOUND.
> 
> WQ_PERCPU is included in ordered_flags after commit 69635d7f4b34 ("fs:
> WQ_PERCPU added to alloc_workqueue users") and WQ_UNBOUND is set in
> alloc_ordered_workqueue(), which btrfs_alloc_ordered_workqueue() calls.
> 
> Drop WQ_PERCPU from ordered_flags, as alloc_ordered_workqueue() notes
> that only WQ_FREEZABLE and WQ_MEM_RECLAIM are meaningful.
> 
> Fixes: 69635d7f4b34 ("fs: WQ_PERCPU added to alloc_workqueue users")
> Fixes: 21c05ca88a54 ("workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present")
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> ---
> This should go in via the workqueue tree that adds the warning.

Acked-by: David Sterba <dsterba@suse.com>

Re: [PATCH] btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()

[Marco Crivellari]

On Tue, Jun 2, 2026 at 4:46 AM Nathan Chancellor <nathan@kernel.org> wrote:
>
> After commit 21c05ca88a54 ("workqueue: Add warnings and ensure one among
> WQ_PERCPU or WQ_UNBOUND is present"), there is a warning from the
> btrfs-qgroup-rescan workqueue at run time:
>
>   workqueue: btrfs-qgroup-rescan uses both WQ_PERCPU and WQ_UNBOUND. Dropped WQ_PERCPU, keeping WQ_UNBOUND.
>
> WQ_PERCPU is included in ordered_flags after commit 69635d7f4b34 ("fs:
> WQ_PERCPU added to alloc_workqueue users") and WQ_UNBOUND is set in
> alloc_ordered_workqueue(), which btrfs_alloc_ordered_workqueue() calls.
>
> Drop WQ_PERCPU from ordered_flags, as alloc_ordered_workqueue() notes
> that only WQ_FREEZABLE and WQ_MEM_RECLAIM are meaningful.

Acked-by: Marco Crivellari <marco.crivellari@suse.com>

Thanks!

--

Marco Crivellari

SUSE Labs

Re: [PATCH] btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()

[Breno Leitao]

On Mon, Jun 01, 2026 at 07:46:26PM -0700, Nathan Chancellor wrote:
> After commit 21c05ca88a54 ("workqueue: Add warnings and ensure one among
> WQ_PERCPU or WQ_UNBOUND is present"), there is a warning from the
> btrfs-qgroup-rescan workqueue at run time:
> 
>   workqueue: btrfs-qgroup-rescan uses both WQ_PERCPU and WQ_UNBOUND. Dropped WQ_PERCPU, keeping WQ_UNBOUND.
> 
> WQ_PERCPU is included in ordered_flags after commit 69635d7f4b34 ("fs:
> WQ_PERCPU added to alloc_workqueue users") and WQ_UNBOUND is set in
> alloc_ordered_workqueue(), which btrfs_alloc_ordered_workqueue() calls.
> 
> Drop WQ_PERCPU from ordered_flags, as alloc_ordered_workqueue() notes
> that only WQ_FREEZABLE and WQ_MEM_RECLAIM are meaningful.
> 
> Fixes: 69635d7f4b34 ("fs: WQ_PERCPU added to alloc_workqueue users")
> Fixes: 21c05ca88a54 ("workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present")
> Signed-off-by: Nathan Chancellor <nathan@kernel.org>

Reviewed-by: Breno Leitao <leitao@debian.org>

This will solve the following issue I am seeing in linux-next:

   workqueue: btrfs-qgroup-rescan uses both WQ_PERCPU and WQ_UNBOUND. Dropped WQ_PERCPU, keeping WQ_UNBOUND.

Re: [PATCH] btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()

[Nathan Chancellor]

Hi Tejun,

Could you please pick up this patch for -next to clear up this warning?
Not sure if this was on your radar since it is a btrfs change.

On Thu, Jun 04, 2026 at 02:52:38AM -0700, Breno Leitao wrote:
> On Mon, Jun 01, 2026 at 07:46:26PM -0700, Nathan Chancellor wrote:
> > After commit 21c05ca88a54 ("workqueue: Add warnings and ensure one among
> > WQ_PERCPU or WQ_UNBOUND is present"), there is a warning from the
> > btrfs-qgroup-rescan workqueue at run time:
> > 
> >   workqueue: btrfs-qgroup-rescan uses both WQ_PERCPU and WQ_UNBOUND. Dropped WQ_PERCPU, keeping WQ_UNBOUND.
> > 
> > WQ_PERCPU is included in ordered_flags after commit 69635d7f4b34 ("fs:
> > WQ_PERCPU added to alloc_workqueue users") and WQ_UNBOUND is set in
> > alloc_ordered_workqueue(), which btrfs_alloc_ordered_workqueue() calls.
> > 
> > Drop WQ_PERCPU from ordered_flags, as alloc_ordered_workqueue() notes
> > that only WQ_FREEZABLE and WQ_MEM_RECLAIM are meaningful.
> > 
> > Fixes: 69635d7f4b34 ("fs: WQ_PERCPU added to alloc_workqueue users")
> > Fixes: 21c05ca88a54 ("workqueue: Add warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present")
> > Signed-off-by: Nathan Chancellor <nathan@kernel.org>
> 
> Reviewed-by: Breno Leitao <leitao@debian.org>
> 
> This will solve the following issue I am seeing in linux-next:
> 
>    workqueue: btrfs-qgroup-rescan uses both WQ_PERCPU and WQ_UNBOUND. Dropped WQ_PERCPU, keeping WQ_UNBOUND.

-- 
Cheers,
Nathan

Re: [PATCH] btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()

[Breno Leitao]

On Thu, Jun 04, 2026 at 02:58:11PM -0700, Nathan Chancellor wrote:
> Could you please pick up this patch for -next to clear up this warning?
> Not sure if this was on your radar since it is a btrfs change.

Why not getting this through the btrfs tree, given this is a btrfs
change?

--breno

Re: [PATCH] btrfs: Drop WQ_PERCPU from ordered_flags in btrfs_init_workqueues()

[Nathan Chancellor]

On Fri, Jun 05, 2026 at 01:48:24AM -0700, Breno Leitao wrote:
> On Thu, Jun 04, 2026 at 02:58:11PM -0700, Nathan Chancellor wrote:
> > Could you please pick up this patch for -next to clear up this warning?
> > Not sure if this was on your radar since it is a btrfs change.
> 
> Why not getting this through the btrfs tree, given this is a btrfs
> change?

The warning is only visible after commit 21c05ca88a54 ("workqueue: Add
warnings and ensure one among WQ_PERCPU or WQ_UNBOUND is present") in
the workqueue tree. If it goes via the btrfs tree, there could be a
period during the merge window where the warning appears if the
workqueue tree is merged before the btrfs tree. Not the biggest deal
since it is a runtime warning but there are already other patches in the
workqueue tree that avoid warnings and David already provided an Ack, so
I don't see a reason to deviate from the proper process here. Up to
Tejun and the btrfs folks though.

-- 
Cheers,
Nathan