Linux SCSI subsystem development
 help / color / mirror / Atom feed
From: Ming Lei <ming.lei@redhat.com>
To: Daejun Park <daejun7.park@samsung.com>
Cc: ALIM AKHTAR <alim.akhtar@samsung.com>,
	"avri.altman@wdc.com" <avri.altman@wdc.com>,
	"jejb@linux.ibm.com" <jejb@linux.ibm.com>,
	"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
	"huobean@gmail.com" <huobean@gmail.com>,
	"bvanassche@acm.org" <bvanassche@acm.org>,
	Keoseong Park <keosung.park@samsung.com>,
	"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	ming.lei@redhat.com
Subject: Re: [PATCH] scsi: ufs: Fix proper API to send HPB pre-request
Date: Fri, 29 Oct 2021 09:32:36 +0800	[thread overview]
Message-ID: <YXtPNIDzeln8zBCn@T590> (raw)
In-Reply-To: <20211027223619epcms2p60bbc74c9ba9757c58709a99acd0892ff@epcms2p6>

On Thu, Oct 28, 2021 at 07:36:19AM +0900, Daejun Park wrote:
> This patch addresses the issue of using the wrong API to create a
> pre_request for HPB READ.
> HPB READ candidate that require a pre-request will try to allocate a
> pre-request only during request_timeout_ms (default: 0). Otherwise, it is

Can you explain about 'only during request_timeout_ms'?

From the following code in ufshpb_prep(), the pre-request is allocated
for each READ IO in case of (!ufshpb_is_legacy(hba) && ufshpb_is_required_wb(hpb,
transfer_len)).

   if (!ufshpb_is_legacy(hba) &&
            ufshpb_is_required_wb(hpb, transfer_len)) {
                err = ufshpb_issue_pre_req(hpb, cmd, &read_id);

> passed as normal READ, so deadlock problem can be resolved.
> 
> Signed-off-by: Daejun Park <daejun7.park@samsung.com>
> ---
>  drivers/scsi/ufs/ufshpb.c | 11 +++++------
>  drivers/scsi/ufs/ufshpb.h |  1 +
>  2 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/scsi/ufs/ufshpb.c b/drivers/scsi/ufs/ufshpb.c
> index 02fb51ae8b25..3117bd47d762 100644
> --- a/drivers/scsi/ufs/ufshpb.c
> +++ b/drivers/scsi/ufs/ufshpb.c
> @@ -548,8 +548,7 @@ static int ufshpb_execute_pre_req(struct ufshpb_lu *hpb, struct scsi_cmnd *cmd,
>  				 read_id);
>  	rq->cmd_len = scsi_command_size(rq->cmd);
>  
> -	if (blk_insert_cloned_request(q, req) != BLK_STS_OK)
> -		return -EAGAIN;
> +	blk_execute_rq_nowait(NULL, req, true, ufshpb_pre_req_compl_fn);

Be care with above change, blk_insert_cloned_request() allocates
driver tag and issues the request to LLD directly, then returns the
result. If anything fails in the code path, -EAGAIN is returned.

But blk_execute_rq_nowait() simply queued the request in block layer,
and run hw queue. It doesn't allocate driver tag, and doesn't issue it
to LLD.

So ufshpb_execute_pre_req() may think the pre-request is issued to LLD
successfully, but actually not, maybe never. What will happen after the
READ IO is issued to device, but the pre-request(write buffer) isn't
sent to device?

>  
>  	hpb->stats.pre_req_cnt++;
>  
> @@ -2315,19 +2314,19 @@ struct attribute_group ufs_sysfs_hpb_param_group = {
>  static int ufshpb_pre_req_mempool_init(struct ufshpb_lu *hpb)
>  {
>  	struct ufshpb_req *pre_req = NULL, *t;
> -	int qd = hpb->sdev_ufs_lu->queue_depth / 2;
>  	int i;
>  
>  	INIT_LIST_HEAD(&hpb->lh_pre_req_free);
>  
> -	hpb->pre_req = kcalloc(qd, sizeof(struct ufshpb_req), GFP_KERNEL);
> -	hpb->throttle_pre_req = qd;
> +	hpb->pre_req = kcalloc(HPB_INFLIGHT_PRE_REQ, sizeof(struct ufshpb_req),
> +			       GFP_KERNEL);
> +	hpb->throttle_pre_req = HPB_INFLIGHT_PRE_REQ;
>  	hpb->num_inflight_pre_req = 0;
>  
>  	if (!hpb->pre_req)
>  		goto release_mem;
>  
> -	for (i = 0; i < qd; i++) {
> +	for (i = 0; i < HPB_INFLIGHT_PRE_REQ; i++) {
>  		pre_req = hpb->pre_req + i;
>  		INIT_LIST_HEAD(&pre_req->list_req);
>  		pre_req->req = NULL;
> diff --git a/drivers/scsi/ufs/ufshpb.h b/drivers/scsi/ufs/ufshpb.h
> index a79e07398970..411a6d625f53 100644
> --- a/drivers/scsi/ufs/ufshpb.h
> +++ b/drivers/scsi/ufs/ufshpb.h
> @@ -50,6 +50,7 @@
>  #define HPB_RESET_REQ_RETRIES			10
>  #define HPB_MAP_REQ_RETRIES			5
>  #define HPB_REQUEUE_TIME_MS			0
> +#define HPB_INFLIGHT_PRE_REQ			4

Can you explain how this change solves the deadlock?

Thanks,
Ming


  parent reply	other threads:[~2021-10-29  1:33 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20211027223619epcms2p60bbc74c9ba9757c58709a99acd0892ff@epcms2p6>
2021-10-27 22:36 ` [PATCH] scsi: ufs: Fix proper API to send HPB pre-request Daejun Park
2021-10-28  4:16   ` Bart Van Assche
2021-10-28 14:28   ` James Bottomley
2021-10-28 15:27     ` Christoph Hellwig
2021-10-28 17:07       ` Bart Van Assche
2021-10-28 17:10         ` Christoph Hellwig
2021-10-28 15:59     ` Bart Van Assche
2021-10-28 19:12       ` James Bottomley
2021-10-28 20:04         ` Bart Van Assche
2021-10-28 20:12           ` James Bottomley
2021-10-28 21:20         ` Daejun Park
2021-10-28 15:22   ` James Bottomley
2021-10-29  1:32   ` Ming Lei [this message]
2021-10-29  1:50     ` Daejun Park
2021-10-29  2:10       ` Ming Lei
2021-10-29  2:50         ` Daejun Park
2021-10-29  3:14           ` Ming Lei
2021-10-29  4:39             ` Daejun Park

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=YXtPNIDzeln8zBCn@T590 \
    --to=ming.lei@redhat.com \
    --cc=alim.akhtar@samsung.com \
    --cc=avri.altman@wdc.com \
    --cc=bvanassche@acm.org \
    --cc=daejun7.park@samsung.com \
    --cc=huobean@gmail.com \
    --cc=jejb@linux.ibm.com \
    --cc=keosung.park@samsung.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox