Received-SPF: pass (google.com: domain of linux-kernel+bounces-73518-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:40f1:3f00::1 as permitted sender) client-ip=2604:1380:40f1:3f00::1;
Sender: Tejun Heo <htejun@gmail.com>
Date: Tue, 20 Feb 2024 08:38:02 -1000
From: Tejun Heo <tj@kernel.org>
To: Lai Jiangshan <jiangshanlai@gmail.com>
Cc: torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	allen.lkml@gmail.com, kernel-team@meta.com
Subject: Re: [PATCH 12/17] workqueue: Implement disable/enable for (delayed)
 work items
Message-ID: <ZdTxisk3zp_eXDVb@slm.duckdns.org>
References: <20240216180559.208276-1-tj@kernel.org>
 <20240216180559.208276-13-tj@kernel.org>
 <CAJhGHyCOgrU9TC9o97LpvAEL2p+Dgt=uN0mo01Gr7HadVSD-Ag@mail.gmail.com>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAJhGHyCOgrU9TC9o97LpvAEL2p+Dgt=uN0mo01Gr7HadVSD-Ag@mail.gmail.com>

Hello,

On Tue, Feb 20, 2024 at 03:22:26PM +0800, Lai Jiangshan wrote:
> > - A work item carries 10bit disable count in work->data while not queued.
> >   The access to the count is synchronized by the PENDING bit like all other
> >   parts of work->data.
> 
> It is 16bit disable count in the code.

Fixed.

> It misses the same handling  at queue_work_node() and queue_rcu_work().

Oops, fixed queued_work_node() but I don't think the latter is an issue
given that calling work interface functions in the embedded work is not
supported and rcu_work can't even be canceled.

I'm not quite sure flush_delayed_work() is safe. Will think more about that.

> But it is bad idea to cancel or disable rcu work since it can be possibly
> in the rcu's waiting list.

Yeah, this isn't currently supported. If we want to add this, we'd have to
have a mechanism to shoot it down from RCU's pending list.

Thanks.

-- 
tejun