From: Jiri Slaby <jirislaby@kernel.org>
To: Breno Leitao <leitao@debian.org>, Tejun Heo <tj@kernel.org>,
Lai Jiangshan <jiangshanlai@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>
Cc: linux-kernel@vger.kernel.org, Omar Sandoval <osandov@osandov.com>,
Song Liu <song@kernel.org>,
Danielle Costantino <dcostantino@meta.com>,
kasan-dev@googlegroups.com, Petr Mladek <pmladek@suse.com>,
kernel-team@meta.com
Subject: Re: [PATCH v2 4/5] workqueue: Show all busy workers in stall diagnostics
Date: Thu, 7 May 2026 12:20:33 +0200 [thread overview]
Message-ID: <4ed2b000-2306-49fe-87b8-8bfd7f6b6d43@kernel.org> (raw)
In-Reply-To: <20260305-wqstall_start-at-v2-4-b60863ee0899@debian.org>
On 05. 03. 26, 17:15, Breno Leitao wrote:
> show_cpu_pool_hog() only prints workers whose task is currently running
> on the CPU (task_is_running()). This misses workers that are busy
> processing a work item but are sleeping or blocked — for example, a
> worker that clears PF_WQ_WORKER and enters wait_event_idle(). Such a
> worker still occupies a pool slot and prevents progress, yet produces
> an empty backtrace section in the watchdog output.
>
> This is happening on real arm64 systems, where
> toggle_allocation_gate() IPIs every single CPU in the machine (which
> lacks NMI), causing workqueue stalls that show empty backtraces because
> toggle_allocation_gate() is sleeping in wait_event_idle().
>
> Remove the task_is_running() filter so every in-flight worker in the
> pool's busy_hash is dumped. The busy_hash is protected by pool->lock,
> which is already held.
>
> Signed-off-by: Breno Leitao <leitao@debian.org>
> ---
> kernel/workqueue.c | 28 +++++++++++++---------------
> 1 file changed, 13 insertions(+), 15 deletions(-)
>
> diff --git a/kernel/workqueue.c b/kernel/workqueue.c
> index 56d8af13843f8..09b9ad78d566c 100644
> --- a/kernel/workqueue.c
> +++ b/kernel/workqueue.c
> @@ -7583,9 +7583,9 @@ MODULE_PARM_DESC(panic_on_stall_time, "Panic if stall exceeds this many seconds
>
> /*
> * Show workers that might prevent the processing of pending work items.
> - * The only candidates are CPU-bound workers in the running state.
> - * Pending work items should be handled by another idle worker
> - * in all other situations.
> + * A busy worker that is not running on the CPU (e.g. sleeping in
> + * wait_event_idle() with PF_WQ_WORKER cleared) can stall the pool just as
> + * effectively as a CPU-bound one, so dump every in-flight worker.
> */
> static void show_cpu_pool_hog(struct worker_pool *pool)
> {
> @@ -7596,19 +7596,17 @@ static void show_cpu_pool_hog(struct worker_pool *pool)
> raw_spin_lock_irqsave(&pool->lock, irq_flags);
>
> hash_for_each(pool->busy_hash, bkt, worker, hentry) {
> - if (task_is_running(worker->task)) {
We see dumps from non-existent cpus on 7.0 like:
BUG: workqueue lockup - pool cpus=144 node=0 flags=0x4 nice=0 stuck
for 168224s!
...
Showing busy workqueues and worker pools:
workqueue rcu_gp: flags=0x108
pwq 578: cpus=144 node=0 flags=0x4 nice=0 active=3 refcnt=4
in:
https://bugzilla.suse.com/show_bug.cgi?id=1263947
?
Can this (or other patch from the series) cause this? Should there be
something like cpu_online() instead of task_is_running() somewhere?
> - /*
> - * Defer printing to avoid deadlocks in console
> - * drivers that queue work while holding locks
> - * also taken in their write paths.
> - */
> - printk_deferred_enter();
> + /*
> + * Defer printing to avoid deadlocks in console
> + * drivers that queue work while holding locks
> + * also taken in their write paths.
> + */
> + printk_deferred_enter();
>
> - pr_info("pool %d:\n", pool->id);
> - sched_show_task(worker->task);
> + pr_info("pool %d:\n", pool->id);
> + sched_show_task(worker->task);
>
> - printk_deferred_exit();
> - }
> + printk_deferred_exit();
> }
>
> raw_spin_unlock_irqrestore(&pool->lock, irq_flags);
thanks,
--
js
suse labs
next parent reply other threads:[~2026-05-07 10:20 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20260305-wqstall_start-at-v2-0-b60863ee0899@debian.org>
[not found] ` <20260305-wqstall_start-at-v2-4-b60863ee0899@debian.org>
2026-05-07 10:20 ` Jiri Slaby [this message]
2026-05-07 13:11 ` [PATCH v2 4/5] workqueue: Show all busy workers in stall diagnostics Breno Leitao
2026-05-11 5:21 ` Jiri Slaby
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4ed2b000-2306-49fe-87b8-8bfd7f6b6d43@kernel.org \
--to=jirislaby@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=dcostantino@meta.com \
--cc=jiangshanlai@gmail.com \
--cc=kasan-dev@googlegroups.com \
--cc=kernel-team@meta.com \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=osandov@osandov.com \
--cc=pmladek@suse.com \
--cc=song@kernel.org \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox