| Message ID | 20231016020314.1269636-4-haowenchao2@huawei.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | SCSI: Fix issues between removing device and error handle | expand |
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c index 2550f8cd182a..57e3cc556549 100644 --- a/drivers/scsi/scsi_error.c +++ b/drivers/scsi/scsi_error.c @@ -1568,7 +1568,7 @@ static int scsi_eh_bus_device_reset(struct Scsi_Host *shost, struct scsi_device *sdev; enum scsi_disposition rtn; - shost_for_each_device(sdev, shost) { + shost_for_each_device_include_deleted(sdev, shost) { if (scsi_host_eh_past_deadline(shost)) { SCSI_LOG_ERROR_RECOVERY(3, sdev_printk(KERN_INFO, sdev,
shost_for_each_device() would skip devices which is in progress of removing, so scsi_try_bus_device_reset() for these devices would be skipped in scsi_eh_bus_device_reset() with following order: T1: T2:scsi_error_handle __scsi_remove_device scsi_device_set_state(sdev, SDEV_DEL) // would skip device with SDEV_DEL state shost_for_each_device() scsi_try_bus_device_reset flush all commands ... releasing and free scsi_device Some drivers like smartpqi only implement eh_device_reset_handler, if device reset is skipped, the commands which had been sent to firmware or devices hardware are not cleared. The error handle would flush all these commands in scsi_unjam_host(). When the commands are finished by hardware, use after free issue is triggered. Fix this issue by using shost_for_each_device_include_deleted() to iterate devices in scsi_eh_bus_device_reset(). Signed-off-by: Wenchao Hao <haowenchao2@huawei.com> --- drivers/scsi/scsi_error.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)