All of lore.kernel.org
 help / color / mirror / Atom feed
From: hongwus@codeaurora.org
To: Can Guo <cang@codeaurora.org>
Cc: asutoshd@codeaurora.org, nguyenb@codeaurora.org,
	rnayak@codeaurora.org, sh425.lee@samsung.com,
	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>,
	Bart Van Assche <bvanassche@acm.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 2/9] scsi: ufs: Fix imbalanced scsi_block_reqs_cnt caused by ufshcd_hold()
Date: Thu, 23 Jul 2020 11:20:50 +0800	[thread overview]
Message-ID: <307b91fd2d7a59a3e1caa1819e2593e5@codeaurora.org> (raw)
In-Reply-To: <1595471649-25675-3-git-send-email-cang@codeaurora.org>

Hi Can,
On 2020-07-23 10:34, 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 99bd3e4..2907828 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.

Yes, queue_work() may fail for some reasons. We should make sure 
scsi_block_reqs_cnt is balanced. Your change looks good to me since it 
touches scsi_block_reqs_cnt only when the condition is met.

Reviewed-by: Hongwu Su <hongwus@codeaurora.org>


  reply	other threads:[~2020-07-23  3:21 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-23  2:33 [PATCH v5 0/9] Fix up and simplify error recovery mechanism Can Guo
2020-07-23  2:34 ` [PATCH v5 1/9] scsi: ufs: Add checks before setting clk-gating states Can Guo
2020-07-23  2:45   ` hongwus
2020-07-23  2:34 ` [PATCH v5 2/9] scsi: ufs: Fix imbalanced scsi_block_reqs_cnt caused by ufshcd_hold() Can Guo
2020-07-23  3:20   ` hongwus [this message]
2020-07-23  2:34 ` [PATCH v5 3/9] ufs: ufs-qcom: Fix race conditions caused by func ufs_qcom_testbus_config Can Guo
2020-07-23  3:38   ` hongwus
2020-07-23  2:34 ` [PATCH v5 4/9] scsi: ufs-qcom: Fix schedule while atomic error in ufs_qcom_dump_dbg_regs Can Guo
2020-07-23  2:34 ` [PATCH v5 5/9] scsi: ufs: Add some debug infos to ufshcd_print_host_state Can Guo
2020-07-23  2:34 ` [PATCH v5 6/9] scsi: ufs: Fix concurrency of error handler and other error recovery paths Can Guo
2020-07-23  2:34 ` [PATCH v5 7/9] scsi: ufs: Recover hba runtime PM error in error handler Can Guo
2020-07-23  2:34 ` [PATCH v5 8/9] scsi: ufs: Move dumps in IRQ handler to " Can Guo
2020-07-23  2:34 ` [PATCH v5 9/9] scsi: ufs: Fix a racing problem btw error handler and runtime PM ops 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=307b91fd2d7a59a3e1caa1819e2593e5@codeaurora.org \
    --to=hongwus@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=cang@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=sh425.lee@samsung.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.