[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZdwIoyRllkjnSTAH@boqun-archlinux>
Date: Sun, 25 Feb 2024 19:42:27 -0800
From: Boqun Feng <boqun.feng@...il.com>
To: Tejun Heo <tj@...nel.org>
Cc: jiangshanlai@...il.com, torvalds@...ux-foundation.org,
linux-kernel@...r.kernel.org, allen.lkml@...il.com,
kernel-team@...a.com
Subject: Re: [PATCH 12/17] workqueue: Implement disable/enable for (delayed)
work items
On Fri, Feb 16, 2024 at 08:04:53AM -1000, Tejun Heo wrote:
[...]
> +/**
> + * enable_work - Enable a work item
> + * @work: work item to enable
> + *
> + * Undo disable_work[_sync]() by decrementing @work's disable count. @work can
> + * only be queued if its disable count is 0.
> + *
> + * Must be called from a sleepable context. Returns %true if the disable count
> + * reached 0. Otherwise, %false.
> + */
> +bool enable_work(struct work_struct *work)
> +{
> + struct work_offq_data offqd;
> + unsigned long irq_flags;
> +
> + work_grab_pending(work, 0, &irq_flags);
> +
> + work_offqd_unpack(&offqd, *work_data_bits(work));
> + work_offqd_enable(&offqd);
> + set_work_pool_and_clear_pending(work, offqd.pool_id,
> + work_offqd_pack_flags(&offqd));
> + local_irq_enable();
Maybe
local_irq_restore(irq_flags);
?
Because in a later patch, you make this funciton callable in any
context, so it may be called with irq disabled.
Regards,
Boqun
> +
> + return !offqd.disable;
> +}
> +EXPORT_SYMBOL_GPL(enable_work);
[..]
Powered by blists - more mailing lists