On 10/23/23 4:28 AM, Hannes Reinecke wrote: > Returning FAST_IO_FAIL from any of the SCSI EH functions is perfectly > valid, and indicates that the request could not be executed due to > the transport being busy. I'm not sure if that's completely correct or maybe we have a different view of what it means to be busy. FC, iSCSI and SRP normally return it when the transport is marked as offline/lost, so for normal IO we fail it upwards and userspace gets an error. What drivers use it as temp busy error code? Is it the lpfc one or a snic one? > But that is not an I/O error, and we should return -EAGAIN from > scsi_ioctl_reset() to correctly inform userspace. For the sg_reset example, if you tried to run sg_reset again it would fail. When sg_reset tries to open the device the open function will return failure in the open call because the device is in the transport-offline state for FC/iSCSI/SRP. If you are going to change the return value why not sync it with what we return for normal IO and return BLK_STS_TRANSPORT/-ENOLINK?
