linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Bart Van Assche <bvanassche@acm.org>
To: Stanley Chu <stanley.chu@mediatek.com>
Cc: Lee Sang Hyun <sh425.lee@samsung.com>,
	linux-scsi@vger.kernel.org, alim.akhtar@samsung.com,
	avri.altman@wdc.com, jejb@linux.ibm.com,
	martin.petersen@oracle.com, beanhuo@micron.com,
	asutoshd@codeaurora.org, cang@codeaurora.org,
	grant.jung@samsung.com, sc.suh@samsung.com, hy50.seo@samsung.com,
	kwmad.kim@samsung.com
Subject: Re: [RESEND RFC PATCH v1] scsi: ufs: add retries for SSU
Date: Wed, 22 Jul 2020 08:10:55 -0700	[thread overview]
Message-ID: <893ed1a8-504f-ae87-f5e4-4c1dbc3607a7@acm.org> (raw)
In-Reply-To: <1595409255.27178.17.camel@mtkswgap22>

On 2020-07-22 02:14, Stanley Chu wrote:
> Hi Bart,
> 
> On Sat, 2020-07-18 at 13:30 -0700, Bart Van Assche wrote:
>> On 2020-07-17 00:39, Lee Sang Hyun wrote:
>>> -	ret = scsi_execute(sdp, cmd, DMA_NONE, NULL, 0, NULL, &sshdr,
>>> -			START_STOP_TIMEOUT, 0, 0, RQF_PM, NULL);
>>> -	if (ret) {
>>> -		sdev_printk(KERN_WARNING, sdp,
>>> -			    "START_STOP failed for power mode: %d, result %x\n",
>>> -			    pwr_mode, ret);
>>> -		if (driver_byte(ret) == DRIVER_SENSE)
>>> -			scsi_print_sense_hdr(sdp, NULL, &sshdr);
>>> +	for (retries = 0; retries < SSU_RETRIES; retries++) {
>>> +		ret = scsi_execute(sdp, cmd, DMA_NONE, NULL, 0, NULL, &sshdr,
>>> +				START_STOP_TIMEOUT, 0, 0, RQF_PM, NULL);
>>> +		if (ret) {
>>> +			sdev_printk(KERN_WARNING, sdp,
>>> +				    "START_STOP failed for power mode: %d, result %x\n",
>>> +				    pwr_mode, ret);
>>> +			if (driver_byte(ret) == DRIVER_SENSE)
>>> +				scsi_print_sense_hdr(sdp, NULL, &sshdr);
>>> +		} else {
>>> +			break;
>>> +		}
>>
>> The ninth argument of scsi_execute() is called 'retries'. Wouldn't it be
>> better to pass a nonzero value as the 'retries' argument of
>> scsi_execute() instead of adding a loop around the scsi_execute() call?
> 
> If a SCSI command issued via scsi_execute() encounters "timeout" or
> "check condition", scsi_noretry_cmd() will return 1 (true) because
> blk_rq_is_passthrough() is true due to REQ_OP_SCSI_IN or REQ_OP_SCSI_OUT
> flag was set to this SCSI command by scsi_execute(). Therefore even a
> non-zero 'retries' value is assigned while calling scsi_execute(), the
> failed command has no chance to be retried since the decision will be
> no-retry by scsi_noretry_cmd().
> 
> (Take command timeout as example)
> scsi_times_out()->scsi_abort_command()->scmd_eh_abort_handler(), here
> scsi_noretry_cmd() returns 1, and then command will be finished (with
> error code) without retry.
> 
> In scsi_noretry_cmd(), there is a comment message in section
> "check_type" as below
> 
> 	/*
> 	 * assume caller has checked sense and determined
> 	 * the check condition was retryable.
> 	 */
> 
> I am not sure if "timeout" and "check condition" cases in such SCSI
> commands issued via scsi_execute() are specially designed to be unable
> to retry.
> 
> Would you have any suggestions if LLD drivers would like to retry these
> kinds of SCSI commands?

How about summarizing the above explanation of why the 'retry' argument
of scsi_execute() cannot be used in a two or three line comment and to
add that comment above the loop introduced by this patch?

Thanks,

Bart.

  reply	other threads:[~2020-07-22 15:10 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20200717074740epcas2p2b1c8e7bf7dc28f13c5a9999373f4601b@epcas2p2.samsung.com>
2020-07-17  7:39 ` [RESEND RFC PATCH v1] scsi: ufs: add retries for SSU Lee Sang Hyun
2020-07-18 20:30   ` Bart Van Assche
2020-07-22  9:14     ` Stanley Chu
2020-07-22 15:10       ` Bart Van Assche [this message]
2020-07-25  3:10         ` Stanley Chu

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=893ed1a8-504f-ae87-f5e4-4c1dbc3607a7@acm.org \
    --to=bvanassche@acm.org \
    --cc=alim.akhtar@samsung.com \
    --cc=asutoshd@codeaurora.org \
    --cc=avri.altman@wdc.com \
    --cc=beanhuo@micron.com \
    --cc=cang@codeaurora.org \
    --cc=grant.jung@samsung.com \
    --cc=hy50.seo@samsung.com \
    --cc=jejb@linux.ibm.com \
    --cc=kwmad.kim@samsung.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sc.suh@samsung.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).