| Message ID | 798FB027101C5650+20250318061125.477498-1-wangyuli@uniontech.com |
|---|---|
| State | New |
| Headers | show |
| Series | [RESEND,v3] scsi: Bypass certain SCSI commands on disks with "use_192_bytes_for_3f" attribute | expand |
> 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. I am really not a fan of using in-kernel workarounds to intercept passthrough commands. Why does does lshw perform a MODE SENSE in the first place? What information is it looking for that isn't available in sysfs?
Hi Martin K. Petersen, On 2025/3/21 09:08, Martin K. Petersen wrote: > I am really not a fan of using in-kernel workarounds to intercept > passthrough commands. > > Why does does lshw perform a MODE SENSE in the first place? What > information is it looking for that isn't available in sysfs? I know this is a workaround to solve the problem at the application layer. The problem is that the kernel does not know what operations the application will do to the disk through ioctl. Intercepting this illegal command in kernel mode will help improve the stability of the system. The following is the log of the exception I caught: 10:22:22 2024] queue cmd =====1a 00 3f 00 ff 00 10:22:22 2024] CPU: 7 PID: 6000 Comm: lshw Tainted: G O 4.19.0-arm64-desktoptest #197 10:22:22 2024] Hardware name: THTF ChaoXiang Series/THTF-FTD3000-ZX200-MF281C, BIOS KL4.28.BXC.D.016.241025.R 10/25/2024 17:51:51 10:22:22 2024] Call trace: 10:22:22 2024] dump_backtrace+0x0/0x1a0 10:22:22 2024] show_stack+0x24/0x30 10:22:22 2024]dump_stack+0xa8/0xcc 10:22:22 2024] queuecommand+0xbc/0x198 [usb_storage] 10:22:22 2024] scsi_dispatch_cmd+0xa4/0x298 10:22:22 2024]scsi_request_fn+0x47c/0x7a8 10:22:22 2024] __blk_run_queue+0x50/0x88 10:22:22 2024] blk_execute_rq_nowait+0xe0/0x160 10:22:22 2024] sg_common_write.isra.11+0x254/0x6c0 10:22:22 2024] sg_new_write.isra.12+0x178/0x308 10:22:22 2024] sg_ioctl+0xeb4/0x11d8 10:22:22 2024] do_vfs_ioctl+0xb0/0x868 10:22:22 2024] ksys_ioctl+0x84/0xb8 10:22:22 2024] __arm64_sys_ioctl+0x28/0x38 10:22:22 2024] el0_svc_common+0xa0/0x190 10:22:22 2024] el0_svc_handler+0xac/0xb8 10:22:22 2024] el0_svc+0x8/0xc I encountered this problem in multiple devices, causing the disk to be unrecognizable. I think it is necessary to do this to make the system more robust. Thanks,
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index f1cfe0bb89b2..96f3418c0cdd 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1565,6 +1565,7 @@ static void scsi_complete(struct request *rq) static int scsi_dispatch_cmd(struct scsi_cmnd *cmd) { struct Scsi_Host *host = cmd->device->host; + struct scsi_device *sdev = cmd->device; int rtn = 0; atomic_inc(&cmd->device->iorequest_cnt); @@ -1613,6 +1614,17 @@ static int scsi_dispatch_cmd(struct scsi_cmnd *cmd) goto done; } + /* + * 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; + } + if (unlikely(host->shost_state == SHOST_DEL)) { cmd->result = (DID_NO_CONNECT << 16); goto done;