[Regression][Stable] sd use scsi_mode_sense with invalid param

[Regression][Stable] sd use scsi_mode_sense with invalid param

[Tom Yan]

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

Re: [Regression][Stable] sd use scsi_mode_sense with invalid param

[Tom Yan]

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

Re: [Regression][Stable] sd use scsi_mode_sense with invalid param

[Tom Yan]

Hi Greg,

Could you help pulling c749301ebee82eb5e97dec14b6ab31a4aabe37a6 into
the stable branches in which 17b49bcbf8351d3dbe57204468ac34f033ed60bc
has been pulled? Thanks!

Regards,
Tom

On Sat, 27 Nov 2021 at 05:21, Tom Yan <tom.ty89@gmail.com> wrote:
>
> 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

Re: [Regression][Stable] sd use scsi_mode_sense with invalid param

[Damien Le Moal]

On 2021/11/27 6:33, Tom Yan wrote:
> Hi Greg,
> 
> Could you help pulling c749301ebee82eb5e97dec14b6ab31a4aabe37a6 into
> the stable branches in which 17b49bcbf8351d3dbe57204468ac34f033ed60bc
> has been pulled? Thanks!

Yeah, in retrospect, these 2 patches should really have been squashed together.
Sorry about that. Note that none of these were marked for stable though. I think
that Sasha's bot picked-up automatically
17b49bcbf8351d3dbe57204468ac34f033ed60bc for stable because of the "Fix" in the
commit title. But c749301ebee82eb5e97dec14b6ab31a4aabe37a6 also has "Fix" in its
title but was not picked-up. Weird.

Greg, Martin,

To fix this, c749301ebee82eb5e97dec14b6ab31a4aabe37a6 is needed in stable !

Reference: https://bugzilla.kernel.org/show_bug.cgi?id=215137

Thanks.

> 
> Regards,
> Tom
> 
> On Sat, 27 Nov 2021 at 05:21, Tom Yan <tom.ty89@gmail.com> wrote:
>>
>> 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


-- 
Damien Le Moal
Western Digital Research

Re: [Regression][Stable] sd use scsi_mode_sense with invalid param

[Greg KH]

On Sat, Nov 27, 2021 at 10:15:51AM +0900, Damien Le Moal wrote:
> On 2021/11/27 6:33, Tom Yan wrote:
> > Hi Greg,
> > 
> > Could you help pulling c749301ebee82eb5e97dec14b6ab31a4aabe37a6 into
> > the stable branches in which 17b49bcbf8351d3dbe57204468ac34f033ed60bc
> > has been pulled? Thanks!
> 
> Yeah, in retrospect, these 2 patches should really have been squashed together.
> Sorry about that. Note that none of these were marked for stable though. I think
> that Sasha's bot picked-up automatically
> 17b49bcbf8351d3dbe57204468ac34f033ed60bc for stable because of the "Fix" in the
> commit title. But c749301ebee82eb5e97dec14b6ab31a4aabe37a6 also has "Fix" in its
> title but was not picked-up. Weird.
> 
> Greg, Martin,
> 
> To fix this, c749301ebee82eb5e97dec14b6ab31a4aabe37a6 is needed in stable !
> 
> Reference: https://bugzilla.kernel.org/show_bug.cgi?id=215137

Now queued up, thanks.

greg k-h