From: Can Guo <cang@codeaurora.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org,
hongwus@codeaurora.org, rnayak@codeaurora.org,
linux-scsi@vger.kernel.org, kernel-team@android.com,
saravanak@google.com, salyzyn@google.com,
Alim Akhtar <alim.akhtar@samsung.com>,
Avri Altman <avri.altman@wdc.com>,
"James E.J. Bottomley" <jejb@linux.ibm.com>,
"Martin K. Petersen" <martin.petersen@oracle.com>,
Stanley Chu <stanley.chu@mediatek.com>,
Bean Huo <beanhuo@micron.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v2 2/4] scsi: ufs: Fix imbalanced scsi_block_reqs_cnt caused by ufshcd_hold()
Date: Tue, 14 Jul 2020 12:11:01 +0800 [thread overview]
Message-ID: <b9abe84856f5d2f6eced90a55638743c@codeaurora.org> (raw)
In-Reply-To: <5470be4c-cfa4-ebe5-a817-e53f26c7eaf6@acm.org>
On 2020-07-14 11:41, Bart Van Assche wrote:
> On 2020-07-13 19:28, Can Guo wrote:
>> The scsi_block_reqs_cnt increased in ufshcd_hold() is supposed to be
>> decreased back in ufshcd_ungate_work() in a paired way. However, if
>> specific ufshcd_hold/release sequences are met, it is possible that
>> scsi_block_reqs_cnt is increased twice but only one ungate work is
>> queued. To make sure scsi_block_reqs_cnt is handled by ufshcd_hold()
>> and
>> ufshcd_ungate_work() in a paired way, increase it only if queue_work()
>> returns true.
>>
>> Signed-off-by: Can Guo <cang@codeaurora.org>
>> ---
>> drivers/scsi/ufs/ufshcd.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
>> index ebf7a95..33214bb 100644
>> --- a/drivers/scsi/ufs/ufshcd.c
>> +++ b/drivers/scsi/ufs/ufshcd.c
>> @@ -1611,12 +1611,12 @@ int ufshcd_hold(struct ufs_hba *hba, bool
>> async)
>> */
>> /* fallthrough */
>> case CLKS_OFF:
>> - ufshcd_scsi_block_requests(hba);
>> hba->clk_gating.state = REQ_CLKS_ON;
>> trace_ufshcd_clk_gating(dev_name(hba->dev),
>> hba->clk_gating.state);
>> - queue_work(hba->clk_gating.clk_gating_workq,
>> - &hba->clk_gating.ungate_work);
>> + if (queue_work(hba->clk_gating.clk_gating_workq,
>> + &hba->clk_gating.ungate_work))
>> + ufshcd_scsi_block_requests(hba);
>> /*
>> * fall through to check if we should wait for this
>> * work to be done or not.
>
> Since "ungate_work" involves calling ufshcd_scsi_unblock_requests() and
> since this patch changes the order in which
> ufshcd_scsi_block_requests()
> and queue_work() are called, I think this patch introduces a race
> condition. Has it been considered to leave the
> ufshcd_scsi_block_requests()
> call where it is and to call ufshcd_scsi_unblock_requests() if
> queue_work() fails?
>
> Thanks,
>
> Bart.
Hi Bart,
The racing does not exist due to we still hold the spin lock here.
Before
release the spin lock, the ungate_work, even it starts to run, cannot
move forward as it needs to require the spin lock once in the entrance.
static void ufshcd_ungate_work(struct work_struct *work)
{
...
spin_lock_irqsave(hba->host->host_lock, flags);
if (hba->clk_gating.state == CLKS_ON) {
spin_unlock_irqrestore(hba->host->host_lock, flags);
goto unblock_reqs;
}
...
}
next prev parent reply other threads:[~2020-07-14 4:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 2:28 [PATCH v2 0/4] Fix up and simplify error recovery mechanism Can Guo
2020-07-14 2:28 ` [PATCH v2 1/4] scsi: ufs: Add checks before setting clk-gating states Can Guo
2020-07-14 3:38 ` Bart Van Assche
2020-07-14 4:11 ` Can Guo
2020-07-14 2:28 ` [PATCH v2 2/4] scsi: ufs: Fix imbalanced scsi_block_reqs_cnt caused by ufshcd_hold() Can Guo
2020-07-14 3:41 ` Bart Van Assche
2020-07-14 4:11 ` Can Guo [this message]
2020-07-14 2:28 ` [PATCH v2 3/4] ufs: ufs-qcom: Fix a few BUGs in func ufs_qcom_dump_dbg_regs() Can Guo
2020-07-14 3:47 ` Bart Van Assche
2020-07-14 4:17 ` Can Guo
2020-07-14 2:28 ` [PATCH v2 4/4] scsi: ufs: Fix up and simplify error recovery mechanism Can Guo
2020-07-14 3:52 ` Bart Van Assche
2020-07-14 4:26 ` Can Guo
2020-07-14 9:13 ` Can Guo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9abe84856f5d2f6eced90a55638743c@codeaurora.org \
--to=cang@codeaurora.org \
--cc=alim.akhtar@samsung.com \
--cc=asutoshd@codeaurora.org \
--cc=avri.altman@wdc.com \
--cc=beanhuo@micron.com \
--cc=bvanassche@acm.org \
--cc=hongwus@codeaurora.org \
--cc=jejb@linux.ibm.com \
--cc=kernel-team@android.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=nguyenb@codeaurora.org \
--cc=rnayak@codeaurora.org \
--cc=salyzyn@google.com \
--cc=saravanak@google.com \
--cc=stanley.chu@mediatek.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.