Re: [PATCH v2 1/3] workqueue: Provide a handshake for canceling BH workers

From: Lai Jiangshan
Date: Wed Sep 03 2025 - 03:33:00 EST


On Tue, Sep 2, 2025 at 12:38 AM Sebastian Andrzej Siewior
<bigeasy@xxxxxxxxxxxxx> wrote:

> @@ -4222,17 +4251,18 @@ static bool __flush_work(struct work_struct *work, bool from_cancel)
> (data & WORK_OFFQ_BH)) {
> /*
> * On RT, prevent a live lock when %current preempted
> - * soft interrupt processing or prevents ksoftirqd from
> - * running by keeping flipping BH. If the BH work item
> - * runs on a different CPU then this has no effect other
> - * than doing the BH disable/enable dance for nothing.
> - * This is copied from
> - * kernel/softirq.c::tasklet_unlock_spin_wait().
> + * soft interrupt processing by blocking on lock which
> + * is owned by the thread invoking the callback.
> */
> while (!try_wait_for_completion(&barr.done)) {
> if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
> - local_bh_disable();
> - local_bh_enable();
> + struct worker_pool *pool;
> +
> + mutex_lock(&wq_pool_mutex);
> + pool = get_work_pool(work);
> + if (pool)
> + workqueue_callback_cancel_wait_running(pool);
> + mutex_unlock(&wq_pool_mutex);

The goal is to avoid using a potentially sleeping function in
__flush_work() for BH work items on PREEMPT_RT, but
mutex_lock(&wq_pool_mutex) is not appropriate in this context.

To obtain the pool of a work item, the preferred approach is to use
rcu_read_lock() together with get_work_pool(work), as is done in
start_flush_work().


> } else {
> cpu_relax();
> }