[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ad1ba59a-3a67-4b3c-a05d-c4e56405cc19@acm.org>
Date: Mon, 24 Feb 2025 10:11:58 -0800
From: Bart Van Assche <bvanassche@....org>
To: WangYuli <wangyuli@...ontech.com>, James.Bottomley@...senPartnership.com,
martin.petersen@...cle.com
Cc: linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org,
stern@...land.harvard.edu, zhanjun@...ontech.com, niecheng1@...ontech.com,
guanwentao@...ontech.com, chenlinxuan@...ontech.com,
Xinwei Zhou <zhouxinwei@...ontech.com>, Xu Rao <raoxu@...ontech.com>,
Yujing Ming <mingyujing@...ontech.com>
Subject: Re: [RESEND PATCH v3] scsi: Bypass certain SCSI commands on disks
with "use_192_bytes_for_3f" attribute
On 2/23/25 7:48 PM, WangYuli wrote:
> However, "lshw" disregards the "use_192_bytes_for_3f" attribute and
> transmits data with a length of 0xff bytes via ioctl, which can cause
> some hard drives to hang and become unusable.
lshw is a user space utility. use_192_bytes_for_3f is not exposed to
user space as far as I know. So how can the above statement be correct?
> @@ -1613,6 +1614,17 @@ static int scsi_dispatch_cmd(struct scsi_cmnd *cmd)
> + /*
> + * Before we queue this command, check attribute use_192_bytes_for_3f.
> + * Because transmits data with a length of 0xff bytes via ioctl may
> + * cause some hard drives to hang and become unusable.
> + */
> + if (cmd->cmnd[0] == MODE_SENSE && sdev->use_192_bytes_for_3f &&
> + cmd->cmnd[2] == 0x3f && cmd->cmnd[4] != 192) {
> + cmd->result = DID_ABORT << 16;
> + goto done;
> + }
From include/scsi/scsi_device.h:
unsigned use_192_bytes_for_3f:1; /* ask for 192 bytes from page 0x3f */
The above code uses use_192_bytes_for_3f for another purpose. Please
respect the purpose of the use_192_bytes_for_3f bitfield.
Thanks,
Bart.
Powered by blists - more mailing lists