On 10/27/14 18:59, Christoph Hellwig wrote:
The calling conventions for this function where bad as it could return
-ENODEV both for a device not currently online and a not recognized ioctl.
Add a new scsi_ioctl_block_when_processing_errors function that wraps
scsi_block_when_processing_errors with the a special case for the
SG_SCSI_RESET ioctl command, and handle the SG_SCSI_RESET case itself
in scsi_ioctl. All callers of scsi_ioctl now must call the above helper
to check for the EH state, so that the ioctl handler itself doesn't
have to.
Hello Christoph,
I might be missing some background information here, but it's not clear
to me why the function like scsi_block_when_processing_errors() was
introduced some time ago. What if immediately after error handling has
finished a new request is queued that kicks the error handler again
before the caller of scsi_block_when_processing_errors() has finished
the actions that should not occur concurrently with error handling ? Has
it already been considered to introduce a mutex to serialize error
handling and activity that should not occur concurrently with error
handling ?
Thanks,
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
