[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7953c9c3-d30c-496f-9fb3-15aa1a7e3e4a@acm.org>
Date: Tue, 1 Jun 2021 09:22:46 -0700
From: Bart Van Assche <bvanassche@....org>
To: Can Guo <cang@...eaurora.org>, Avri Altman <Avri.Altman@....com>
Cc: "James E . J . Bottomley" <jejb@...ux.vnet.ibm.com>,
"Martin K . Petersen" <martin.petersen@...cle.com>,
"linux-scsi@...r.kernel.org" <linux-scsi@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
yongmyung lee <ymhungry.lee@...sung.com>,
Daejun Park <daejun7.park@...sung.com>,
"alim.akhtar@...sung.com" <alim.akhtar@...sung.com>,
"asutoshd@...eaurora.org" <asutoshd@...eaurora.org>,
Zang Leigang <zangleigang@...ilicon.com>,
Avi Shchislowski <Avi.Shchislowski@....com>,
Bean Huo <beanhuo@...ron.com>,
"stanley.chu@...iatek.com" <stanley.chu@...iatek.com>
Subject: Re: [PATCH v5 07/10] scsi: ufshpb: Add "Cold" regions timer
On 3/17/21 12:55 AM, Avri Altman wrote:
>> On 2021-03-16 17:21, Avri Altman wrote:
[ ... ]
>>>> And, which lock is protecting rgn->list_expired_rgn? If two
>>>> read_to_handler works
>>>> are running in parallel, one can be inserting it to its expired_list
>>>> while another
>>>> can be deleting it.
>>> The timeout handler, being a delayed work, is meant to run every
>>> polling period.
>>> Originally, I had it protected from 2 handlers running concurrently,
>>> But I removed it following Daejun's comment, which I accepted,
>>> Since it is always scheduled using the same polling period.
>>
>> But one can set the delay to 0 through sysfs, right?
>
> Will restore the protection. Thanks.
(replying to an email from 2.5 months ago)
Hi Can,
How can two read_to_handler works run in parallel? How can it make a
difference whether or not the delay can be set to zero? Are you aware
that since kernel v3.7 (released in 2012) all workqueues are
non-reentrant? See also commit dbf2576e37da ("workqueue: make all
workqueues non-reentrant"). From the description of that commit:
This patch makes all workqueues non-reentrant. If a work item is
executing on a different CPU when queueing is requested, it is
always queued to that CPU. This guarantees that any given work item
can be executing on one CPU at maximum and if a work item is queued
and executing, both are on the same CPU.
Thanks,
Bart.
Powered by blists - more mailing lists