Re: [PATCH 6/7] workqueue: Allow cancel_work_sync() and disable_work() from atomic contexts on BH work items

From: Lai Jiangshan
Date: Wed Feb 21 2024 - 23:36:49 EST


Hello

On Thu, Feb 22, 2024 at 1:43 AM Tejun Heo <tj@xxxxxxxxxx> wrote:

> @@ -4077,11 +4076,37 @@ static bool __flush_work(struct work_struct *work, bool from_cancel)
>
> rcu_read_lock();
> pool = start_flush_work(work, &barr, from_cancel);
> + is_bh = pool && (pool->flags & POOL_BH);
> rcu_read_unlock();
> if (!pool)
> return false;
>
> - wait_for_completion(&barr.done);
> + if (is_bh && from_cancel) {

Can "*work_data_bits(work) & WORK_OFFQ_BH" be used here?
If so, the previous patch will not be needed.

Thanks.
Lai

> + /*
> + * We're flushing a BH work item which is being canceled. It
> + * must have been executing during start_flush_work() and can't
> + * currently be queued. If @work is still executing, we know it
> + * is running in the BH context and thus can be busy-waited.
> + *
> + * 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().
> + */
> + while (!try_wait_for_completion(&barr.done)) {
> + if (IS_ENABLED(CONFIG_PREEMPT_RT)) {
> + local_bh_disable();
> + local_bh_enable();
> + } else {
> + cpu_relax();
> + }
> + }
> + } else {
> + wait_for_completion(&barr.done);
> + }
> +
> destroy_work_on_stack(&barr.work);
> return true;
> }