linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Damien Le Moal <dlemoal@kernel.org>
To: Hannes Reinecke <hare@suse.de>,
	"Ewan D. Milne" <emilne@redhat.com>,
	linux-scsi@vger.kernel.org
Cc: michael.christie@oracle.com, dgilbert@interlog.com, bvanassche@acm.org
Subject: Re: [PATCH v4 6/9] scsi: sd: Check for and retry in case of READ_CAPCITY(10)/(16) returning no data
Date: Mon, 6 Oct 2025 16:20:51 +0900	[thread overview]
Message-ID: <4e014835-9022-442f-a80f-a0276ed3beda@kernel.org> (raw)
In-Reply-To: <915d81dc-eb77-4b8d-aca8-636f1a41a1e7@suse.de>

On 10/6/25 16:10, Hannes Reinecke wrote:
>> -	memset(buffer, 0, 8);
>> +	for (count = 0; count < 3; ++count) {
>> +		memset(buffer, 0, RC10_LEN);
>> +
>> +		the_result = scsi_execute_cmd(sdp, cmd, REQ_OP_DRV_IN,
>> +					      buffer, RC10_LEN, SD_TIMEOUT,
>> +					      sdkp->max_retries, &exec_args);
>> +
>> +		if (the_result || resid != RC10_LEN)
>> +			break;
>>   
> Hmm. What would happen if some data is returned, but less than the
> expected amount?
> We'd be having a hard time parsing that, wouldn't we?

All data received would normally mean success, so result == 0.
Bad devices cases would be success with resid != 0 but less than RC10_LEN. So I
think the break is correct here since the result is checked after the loop.

> 
> So I guess we should check if we had received _all_ data, no?
> 
>> -	the_result = scsi_execute_cmd(sdp, cmd, REQ_OP_DRV_IN, buffer,
>> -				      8, SD_TIMEOUT, sdkp->max_retries,
>> -				      &exec_args);
>> +		/*
>> +		 * If the status was good but nothing was transferred,
>> +		 * we retry. It is a workaround for some buggy devices
>> +		 * or SAT which sometimes do not return any data.
>> +		 */
>> +	}
>>   
>>   	if (the_result > 0) {
>>   		if (media_not_present(sdkp, &sshdr))
>> @@ -2821,6 +2858,12 @@ static int read_capacity_10(struct scsi_disk *sdkp, struct scsi_device *sdp,
>>   		return -EINVAL;
>>   	}
>>   
>> +	if (resid == RC10_LEN) {
>> +		sd_printk(KERN_ERR, sdkp,
>> +			  "Read Capacity(10) returned good status but no data");
>> +		return -EINVAL;
>> +	}
>> +

And here we should just check that resid is 0 to make the checks complete ? This
could be included in the above check with something like:

	if (resid) {
		sd_printk(KERN_ERR, sdkp,
			"Read Capacity(10) good status but incomplete data");
		return -EINVAL;
	}

>>   	sector_size = get_unaligned_be32(&buffer[4]);
>>   	lba = get_unaligned_be32(&buffer[0]);
>>   
> 
> Similar here. I would assume that _any_ resid value larger than zero 
> would render thecapacity value unreliable...
> 
> Cheers,
> 
> Hannes


-- 
Damien Le Moal
Western Digital Research

  reply	other threads:[~2025-10-06  7:20 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-02 19:25 [PATCH v4 0/9] Retry READ CAPACITY(10)/(16) with good status but no data Ewan D. Milne
2025-10-02 19:25 ` [PATCH v4 1/9] scsi: Explicitly specify .ascq = 0x00 for ASC 0x28/0x29 scsi_failures Ewan D. Milne
2025-10-03  4:24   ` Damien Le Moal
2025-10-06  6:59   ` Hannes Reinecke
2025-10-02 19:25 ` [PATCH v4 2/9] scsi: sd: Do not retry ASC 0x3a in read_capacity_10() with any ASCQ Ewan D. Milne
2025-10-03  4:24   ` Damien Le Moal
2025-10-03 14:40     ` Ewan Milne
2025-10-03 15:44       ` Bart Van Assche
2025-10-03 18:40         ` Ewan Milne
2025-10-06 17:54           ` Bart Van Assche
2025-10-02 19:25 ` [PATCH v4 3/9] scsi: sd: Have scsi-ml retry read_capacity_16 errors Ewan D. Milne
2025-10-06  2:00   ` Damien Le Moal
2025-10-06  7:01   ` Hannes Reinecke
2025-10-02 19:25 ` [PATCH v4 4/9] scsi: sd: Avoid passing potentially uninitialized "sense_valid" to read_capacity_error() Ewan D. Milne
2025-10-06  2:02   ` Damien Le Moal
2025-10-06  7:06   ` Hannes Reinecke
2025-10-02 19:25 ` [PATCH v4 5/9] scsi: sd: Remove checks for -EOVERFLOW in sd_read_capacity() Ewan D. Milne
2025-10-06  2:04   ` Damien Le Moal
2025-10-06  7:07   ` Hannes Reinecke
2025-10-02 19:25 ` [PATCH v4 6/9] scsi: sd: Check for and retry in case of READ_CAPCITY(10)/(16) returning no data Ewan D. Milne
2025-10-06  2:06   ` Damien Le Moal
2025-10-06  7:10   ` Hannes Reinecke
2025-10-06  7:20     ` Damien Le Moal [this message]
2025-10-06  7:25       ` Damien Le Moal
2025-10-06 10:59         ` Hannes Reinecke
2025-10-02 19:25 ` [PATCH v4 7/9] scsi: Simplify nested if conditional in scsi_probe_lun() Ewan D. Milne
2025-10-06  2:07   ` Damien Le Moal
2025-10-06  7:11   ` Hannes Reinecke
2025-10-02 19:25 ` [PATCH v4 8/9] scsi: scsi_debug: Add option to suppress returned data but return good status Ewan D. Milne
2025-10-06  2:09   ` Damien Le Moal
2025-10-06  7:12   ` Hannes Reinecke
2025-10-02 19:25 ` [PATCH v4 9/9] scsi: scsi_debug: Add "only_once" module option to inject an error one time Ewan D. Milne
2025-10-06  2:12   ` Damien Le Moal
2025-10-06  7:12   ` Hannes Reinecke

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=4e014835-9022-442f-a80f-a0276ed3beda@kernel.org \
    --to=dlemoal@kernel.org \
    --cc=bvanassche@acm.org \
    --cc=dgilbert@interlog.com \
    --cc=emilne@redhat.com \
    --cc=hare@suse.de \
    --cc=linux-scsi@vger.kernel.org \
    --cc=michael.christie@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;
as well as URLs for NNTP newsgroup(s).