* Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage [not found] ` <ah2bd_V2QHQftm2o@slm.duckdns.org> @ 2026-06-01 17:51 ` Tetsuo Handa 2026-06-10 12:48 ` Tetsuo Handa 0 siblings, 1 reply; 4+ messages in thread From: Tetsuo Handa @ 2026-06-01 17:51 UTC (permalink / raw) To: Tejun Heo, Mark Brown, Linux-Next Mailing List, Linus Torvalds Cc: Marco Crivellari, linux-kernel, Lai Jiangshan, Frederic Weisbecker, Sebastian Andrzej Siewior, Michal Hocko, Breno Leitao 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...) ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage 2026-06-01 17:51 ` [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage Tetsuo Handa @ 2026-06-10 12:48 ` Tetsuo Handa 2026-06-10 15:22 ` Mark Brown 2026-06-10 17:28 ` Nathan Chancellor 0 siblings, 2 replies; 4+ messages in thread From: Tetsuo Handa @ 2026-06-10 12:48 UTC (permalink / raw) To: Tejun Heo, Mark Brown, Linux-Next Mailing List, Linus Torvalds, Marco Crivellari Cc: linux-kernel, Lai Jiangshan, Frederic Weisbecker, Sebastian Andrzej Siewior, Michal Hocko, Breno Leitao 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage 2026-06-10 12:48 ` Tetsuo Handa @ 2026-06-10 15:22 ` Mark Brown 2026-06-10 17:28 ` Nathan Chancellor 1 sibling, 0 replies; 4+ messages in thread From: Mark Brown @ 2026-06-10 15:22 UTC (permalink / raw) To: Tetsuo Handa Cc: Tejun Heo, Linux-Next Mailing List, Linus Torvalds, Marco Crivellari, linux-kernel, Lai Jiangshan, Frederic Weisbecker, Sebastian Andrzej Siewior, Michal Hocko, Breno Leitao [-- 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 --] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage 2026-06-10 12:48 ` Tetsuo Handa 2026-06-10 15:22 ` Mark Brown @ 2026-06-10 17:28 ` Nathan Chancellor 1 sibling, 0 replies; 4+ messages in thread From: Nathan Chancellor @ 2026-06-10 17:28 UTC (permalink / raw) To: Tetsuo Handa, Tejun Heo Cc: Mark Brown, Linux-Next Mailing List, Linus Torvalds, Marco Crivellari, linux-kernel, Lai Jiangshan, Frederic Weisbecker, Sebastian Andrzej Siewior, Michal Hocko, Breno Leitao 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-06-10 17:28 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <20260529130640.220328-1-marco.crivellari@suse.com>
[not found] ` <bdce3ef27e358b704541d403d28206fd@kernel.org>
[not found] ` <a808c387-1087-4826-80de-16252ae315b2@I-love.SAKURA.ne.jp>
[not found] ` <a85feb7a94ee487fb5b236d86b674c58@kernel.org>
[not found] ` <5b2dea50-2850-4876-b6e8-ba94b9a85034@I-love.SAKURA.ne.jp>
[not found] ` <ah2bd_V2QHQftm2o@slm.duckdns.org>
2026-06-01 17:51 ` [PATCH v4 0/2] workqueue: Add warnings and check WQ flags usage Tetsuo Handa
2026-06-10 12:48 ` Tetsuo Handa
2026-06-10 15:22 ` Mark Brown
2026-06-10 17:28 ` Nathan Chancellor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox