show_all_workqueues() and show_cpu_pools_busy_workers() are called
from contexts that already provide RCU read-side protection.

show_all_workqueues() is called from wq_watchdog_timer_fn(), which
runs in softirq context, and from sysrq_handle_showstate() through
__handle_sysrq(), which holds rcu_read_lock().

show_cpu_pools_busy_workers() is called from wq_watchdog_timer_fn()
as well.

Drop the redundant RCU read-side locking from both functions.

Signed-off-by: Kunwu Chan <kunwu.chan@gmail.com>
---
 kernel/workqueue.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 3c034cbc5bb3..266c3549df0f 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -6711,8 +6711,6 @@ void show_all_workqueues(void)
 	struct worker_pool *pool;
 	int pi;
 
-	rcu_read_lock();
-
 	pr_info("Showing busy workqueues and worker pools:\n");
 
 	list_for_each_entry_rcu(wq, &workqueues, list)
@@ -6720,8 +6718,6 @@ void show_all_workqueues(void)
 
 	for_each_pool(pool, pi)
 		show_one_worker_pool(pool);
-
-	rcu_read_unlock();
 }
 
 /**
@@ -7883,15 +7879,11 @@ static void show_cpu_pools_busy_workers(void)
 
 	pr_info("Showing backtraces of busy workers in stalled worker pools:\n");
 
-	rcu_read_lock();
-
 	for_each_pool(pool, pi) {
 		if (pool->cpu_stall)
 			show_cpu_pool_busy_workers(pool);
 
 	}
-
-	rcu_read_unlock();
 }
 
 /*
-- 
2.43.0

Hello, Chan

On Sun, Sep 20, 2026 at 10:46 AM Kunwu Chan <kunwu.chan@gmail.com> wrote:
>
> show_all_workqueues() and show_cpu_pools_busy_workers() are called
> from contexts that already provide RCU read-side protection.
>
> show_all_workqueues() is called from wq_watchdog_timer_fn(), which
> runs in softirq context, and from sysrq_handle_showstate() through
> __handle_sysrq(), which holds rcu_read_lock().
>
> show_cpu_pools_busy_workers() is called from wq_watchdog_timer_fn()
> as well.
>
> Drop the redundant RCU read-side locking from both functions.
>

I don't think relying on other subsystems to already hold RCU is a good idea,
except for contexts like IRQ or scheduler code, but not softirq.

`rcu_read_lock()` has almost no performance cost and makes the required
context clear.

Thanks,
Lai

On Sun, Sep 20, 2026 at 11:08 AM Lai Jiangshan <jiangshanlai@gmail.com> wrote:
>
> Hello, Chan

Thanks, Lai. I see the distinction.

>
> On Sun, Sep 20, 2026 at 10:46 AM Kunwu Chan <kunwu.chan@gmail.com> wrote:
> >
> > show_all_workqueues() and show_cpu_pools_busy_workers() are called
> > from contexts that already provide RCU read-side protection.
> >
> > show_all_workqueues() is called from wq_watchdog_timer_fn(), which
> > runs in softirq context, and from sysrq_handle_showstate() through
> > __handle_sysrq(), which holds rcu_read_lock().
> >
> > show_cpu_pools_busy_workers() is called from wq_watchdog_timer_fn()
> > as well.
> >
> > Drop the redundant RCU read-side locking from both functions.
> >
>
> I don't think relying on other subsystems to already hold RCU is a good idea,
> except for contexts like IRQ or scheduler code, but not softirq.
>
> `rcu_read_lock()` has almost no performance cost and makes the required
> context clear.

I was looking at this primarily from the RCU correctness side: the
current callers already
provide RCU read-side protection, so the locking is redundant for
those call paths.

Your point about the helper's context contract is a separate design
consideration.
I'll take another look at whether these helpers should require caller-provided
RCU protection or establish the context themselves.

Thanks,
Kunwu

>
> Thanks,
> Lai