On 10/26/23 18:50, Mike Christie wrote:
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?
This patch is primarily for sg_reset(), which would return -EIO whenever
one of the EH functions would return FAST_IO_FAIL.
It got triggered by my patch to zfcp, which now returns FAST_IO_FAIL
from host reset as remote port login is happening from a worker thread,
and the devices are not (yet) available.
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?
Good point.
The alternative would be to map FAST_IO_FAIL back to SUCCESS as after
all the host reset completed successfully, and blocked ports are not
really an error.
Lemme check.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Maxfeldstr. 5, 90409 Nürnberg
HRB 36809 (AG Nürnberg), Geschäftsführer: Ivo Totev, Andrew
Myers, Andrew McDonald, Martje Boudien Moerman
