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
next prev parent 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).