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 [off-list ref] wrote:

quoted

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 [off-list ref] wrote:

quoted

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