| Message ID | 1594693693-22466-3-git-send-email-cang@codeaurora.org (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | Fix up and simplify error recovery mechanism | expand |
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.
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; } ... }
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.
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(-)