All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ian Pilcher <arequipeno@gmail.com>
To: stable@vger.kernel.org
Cc: linux-ide@vger.kernel.org
Subject: Re: [PATCH] Revert "ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error"
Date: Tue, 13 Aug 2024 10:08:07 -0500	[thread overview]
Message-ID: <v9fssn$13au$1@ciao.gmane.io> (raw)
In-Reply-To: <20240813131900.1285842-2-cassel@kernel.org>

On 8/13/24 8:19 AM, Niklas Cassel wrote:
> This reverts commit 28ab9769117ca944cb6eb537af5599aa436287a4.
> 
> Sense data can be in either fixed format or descriptor format.
> 
> SAT-6 revision 1, "10.4.6 Control mode page", defines the D_SENSE bit:
> "The SATL shall support this bit as defined in SPC-5 with the following
> exception: if the D_ SENSE bit is set to zero (i.e., fixed format sense
> data), then the SATL should return fixed format sense data for ATA
> PASS-THROUGH commands."
> 
> The libata SATL has always kept D_SENSE set to zero by default. (It is
> however possible to change the value using a MODE SELECT SG_IO command.)
> 
> Failed ATA PASS-THROUGH commands correctly respected the D_SENSE bit,
> however, successful ATA PASS-THROUGH commands incorrectly returned the
> sense data in descriptor format (regardless of the D_SENSE bit).
> 
> Commit 28ab9769117c ("ata: libata-scsi: Honor the D_SENSE bit for
> CK_COND=1 and no error") fixed this bug for successful ATA PASS-THROUGH
> commands.
> 
> However, after commit 28ab9769117c ("ata: libata-scsi: Honor the D_SENSE
> bit for CK_COND=1 and no error"), there were bug reports that hdparm,
> hddtemp, and udisks were no longer working as expected.
> 
> These applications incorrectly assume the returned sense data is in
> descriptor format, without even looking at the RESPONSE CODE field in the
> returned sense data (to see which format the returned sense data is in).
> 
> Considering that there will be broken versions of these applications around
> roughly forever, we are stuck with being bug compatible with older kernels.

I suppose it's a small quibble, but I don't think it's fair to say that
the applications are behaving incorrectly.  They assume that the
returned sense data is in descriptor format because it always was.  That
doesn't seem unreasonable.

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================



  parent reply	other threads:[~2024-08-13 15:13 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-13 13:19 [PATCH] Revert "ata: libata-scsi: Honor the D_SENSE bit for CK_COND=1 and no error" Niklas Cassel
2024-08-13 14:39 ` Martin K. Petersen
2024-08-13 14:53 ` Hannes Reinecke
2024-08-13 15:08 ` Ian Pilcher [this message]
2024-08-14 13:52 ` Niklas Cassel
2024-08-15 14:05 ` Ian Pilcher

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='v9fssn$13au$1@ciao.gmane.io' \
    --to=arequipeno@gmail.com \
    --cc=linux-ide@vger.kernel.org \
    --cc=stable@vger.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.