linux-scsi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tom Yan <tom.ty89@gmail.com>
To: linux-scsi@vger.kernel.org, damien.lemoal@wdc.com,
	martin.petersen@oracle.com, sashal@kernel.org
Subject: Re: [Regression][Stable] sd use scsi_mode_sense with invalid param
Date: Sat, 27 Nov 2021 05:21:33 +0800	[thread overview]
Message-ID: <CAGnHSEmFoAS-ZY6u=ar=O0UU=FPgEuOx5KLcBWkboEVdeFXbGg@mail.gmail.com> (raw)
In-Reply-To: <CAGnHSE=uOEiLUS=Sx5xhSVrx-7kvdriC=RZxuRasZaM2cLmDeQ@mail.gmail.com>

Ahh, looks like the required change to sd
(c749301ebee82eb5e97dec14b6ab31a4aabe37a6) has been added to upstream
but somehow got missed when 17b49bcbf8351d3dbe57204468ac34f033ed60bc
was pulled into stable...

On Sat, 27 Nov 2021 at 05:11, Tom Yan <tom.ty89@gmail.com> wrote:
>
> Hi,
>
> So with 17b49bcbf8351d3dbe57204468ac34f033ed60bc (upstream),
> scsi_mode_sense now returns -EINVAL if len < 8, yet in sd, the first mode
> sense attempted by sd_read_cache_type() is done with (first_)len being
> 4, which results in the failure of the attempt.
>
> Since the commit is merged into stable, my SATA drive (that has
> volatile write cache) is assumed to be a "write through" drive after I
> upgraded from 5.15.4 to 5.15.5, as libata sets use_10_for_ms to 1.
>
> Since sd does not (get to) determine which mode sense command to use,
> should scsi_mode_sense at least accept a special value 0 (which
> first_len would be set to), which is use to refers to the minimum len
> to use for mode sense 6 and 10 respectively (i.e. 4 or 8)?
>
> Regards,
> Tom

  reply	other threads:[~2021-11-26 21:24 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-26 21:11 [Regression][Stable] sd use scsi_mode_sense with invalid param Tom Yan
2021-11-26 21:21 ` Tom Yan [this message]
2021-11-26 21:33   ` Tom Yan
2021-11-27  1:15     ` Damien Le Moal
2021-11-27 11:55       ` Greg KH

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='CAGnHSEmFoAS-ZY6u=ar=O0UU=FPgEuOx5KLcBWkboEVdeFXbGg@mail.gmail.com' \
    --to=tom.ty89@gmail.com \
    --cc=damien.lemoal@wdc.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=sashal@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).