On Fri, 9 Oct 2020 at 01:36, Christoph Hellwig <hch@xxxxxx> wrote:
>
> Ensure the command length is properly set. Previously the command code
> tried to find this out using the command opcode.
The reported problem [1] is fixed by applying this set of two patches on top
of linux next 20201008 tag kernel and tested on arm64, arm and x86_64
and i386 devices and qemu.
Here is the two patches applied on linux next 20201008 tag
[PATCH 1/2] sr: initialize ->cmd_len[PATCH 1/2] sr: initialize ->cmd_len
[PATCH 2/2] scsi: set sc_data_direction to DMA_NONE for no-transfer commands
- Boot test PASS
- mkfs -t ext4 /dev/sda1 test PASS
>
> Fixes: 2ceda20f0a99 ("scsi: core: Move command size detection out of the fast path")
> Reported-by: Qian Cai <cai@xxxxxxxxxx>
> Reported-by: Naresh Kamboju <naresh.kamboju@xxxxxxxxxx>
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
Tested-by: Naresh Kamboju <naresh.kamboju@xxxxxxxxxx>
> ---
> drivers/scsi/sr.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/sr.c b/drivers/scsi/sr.c
> index b74dfd8dc1165e..c20b4391837898 100644
> --- a/drivers/scsi/sr.c
> +++ b/drivers/scsi/sr.c
> @@ -503,6 +503,7 @@ static blk_status_t sr_init_command(struct scsi_cmnd *SCpnt)
> SCpnt->transfersize = cd->device->sector_size;
> SCpnt->underflow = this_count << 9;
> SCpnt->allowed = MAX_RETRIES;
> + SCpnt->cmd_len = 10;
>
> /*
> * This indicates that the command is ready from our end to be queued.
> --
> 2.28.0
>
[1] https://lore.kernel.org/linux-block/yq1zh4w1mrq.fsf@xxxxxxxxxxxxxxxxxxxx/T/#m4fe8f4ccc1f54d93740f310ce80230a92929e94b
