Re: [PATCH 2/6] scsi: split scsi_nonblockable_ioctl

[Bart Van Assche <bvanassche@acm.org>]

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.