From: Igor Pylypiv <ipylypiv@google.com>
To: Niklas Cassel <cassel@kernel.org>
Cc: Damien Le Moal <dlemoal@kernel.org>, Tejun Heo <tj@kernel.org>,
Hannes Reinecke <hare@suse.de>,
linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org,
Akshat Jain <akshatzen@google.com>,
stable@vger.kernel.org
Subject: Re: [PATCH v3 1/6] ata: libata-scsi: Fix offsets for the fixed format sense data
Date: Thu, 27 Jun 2024 21:21:11 +0000 [thread overview]
Message-ID: <Zn3Xx11UIbbJkbxq@google.com> (raw)
In-Reply-To: <Zn1WUhmLglM4iais@ryzen.lan>
On Thu, Jun 27, 2024 at 02:08:50PM +0200, Niklas Cassel wrote:
> Hello Igor, Hannes,
>
> The changes in this patch looks good, however, there is still one thing that
> bothers me:
> https://github.com/torvalds/linux/blob/v6.10-rc5/drivers/ata/libata-scsi.c#L873-L877
>
> Specifically the code in the else statement below:
>
> if (qc->err_mask ||
> tf->status & (ATA_BUSY | ATA_DF | ATA_ERR | ATA_DRQ)) {
> ata_to_sense_error(qc->ap->print_id, tf->status, tf->error,
> &sense_key, &asc, &ascq);
> ata_scsi_set_sense(qc->dev, cmd, sense_key, asc, ascq);
> } else {
> /*
> * ATA PASS-THROUGH INFORMATION AVAILABLE
> * Always in descriptor format sense.
> */
> scsi_build_sense(cmd, 1, RECOVERED_ERROR, 0, 0x1D);
> }
>
> Looking at sat6r01, I see that this is table:
> Table 217 — ATA command results
>
> And this text:
> No error, successful completion or command in progress. The SATL
> shall terminate the command with CHECK CONDITION status with
> the sense key set to RECOVERED ERROR with the additional
> sense code set to ATA PASS-THROUGH INFORMATION
> AVAILABLE (see SPC-5). Descriptor format sense data shall include
> the ATA Status Return sense data descriptor (see 12.2.2.7).
>
> However, I don't see anything in this text that says that the
> sense key should always be in descriptor format sense.
>
> In fact, what will happen if the user has not set the D_SENSE bit
> (libata will default not set it), is that:
>
> The else statement above will be executed, filling in sense key in
> descriptor format, after this if/else, we will continue checking
> if the sense buffer is in descriptor format, or fixed format.
>
> Since the scsi_build_sense(cmd, 1, RECOVERED_ERROR, 0, 0x1D);
> is called with (..., 1, ..., ..., ...) it will always generate
> the sense data in descriptor format, regardless of
> dev->flags ATA_DFLAG_D_SENSE being set or not.
>
> Should perhaps the code in the else statement be:
>
> } else {
> ata_scsi_set_sense(qc->dev, cmd, RECOVERED_ERROR, 0, 0x1D);
> }
>
> So that we actually respect the D_SENSE bit?
>
> (We currently respect if when filling the sense data buffer with
> sense data from REQUEST SENSE EXT, so I'm not sure why we shouldn't
> respect it for successful ATA PASS-THROUGH commands.)
>
Thanks for pointing this out, Niklas! I agree, it seems like there is no
reason to ignore the D_SENSE bit.
Interestingly, the code was using ata_scsi_set_sense() before.
Commit 11093cb1ef56 ("libata-scsi: generate correct ATA pass-through sense)"
changed it to always be in the descriptor format.
>
> Kind regards,
> Niklas
Thanks,
Igor
next prev parent reply other threads:[~2024-06-27 21:22 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20240626230411.3471543-1-ipylypiv@google.com>
2024-06-26 23:04 ` [PATCH v3 1/6] ata: libata-scsi: Fix offsets for the fixed format sense data Igor Pylypiv
2024-06-27 12:08 ` Niklas Cassel
2024-06-27 21:21 ` Igor Pylypiv [this message]
2024-06-28 6:47 ` Hannes Reinecke
2024-06-28 15:49 ` Niklas Cassel
2024-06-28 18:25 ` Niklas Cassel
2024-06-28 23:17 ` Igor Pylypiv
2024-06-26 23:04 ` [PATCH v3 2/6] ata: libata-scsi: Do not overwrite valid sense data when CK_COND=1 Igor Pylypiv
2024-06-27 0:16 ` Damien Le Moal
2024-06-27 20:55 ` Igor Pylypiv
2024-06-28 3:48 ` Damien Le Moal
2024-06-27 14:14 ` Niklas Cassel
2024-06-27 15:15 ` Niklas Cassel
2024-06-27 21:54 ` Igor Pylypiv
2024-06-28 18:44 ` Niklas Cassel
2024-06-28 23:31 ` Igor Pylypiv
2024-06-29 3:09 ` Niklas Cassel
2024-07-01 20:00 ` Igor Pylypiv
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=Zn3Xx11UIbbJkbxq@google.com \
--to=ipylypiv@google.com \
--cc=akshatzen@google.com \
--cc=cassel@kernel.org \
--cc=dlemoal@kernel.org \
--cc=hare@suse.de \
--cc=linux-ide@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=tj@kernel.org \
/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).