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@xxxxxxxxx> 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@xxxxxxxxx> 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
