Re: [PATCH] workqueue: Drop redundant rcu_read_lock() from dump functions

[KunWu Chan]

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

Thanks, Lai. I see the distinction.

>
> On Sun, Sep 20, 2026 at 10:46 AM Kunwu Chan <kunwu.chan@xxxxxxxxx> 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