On Thu, 2018-06-14 at 06:25 -0400, Chaitra P B wrote:
> As a part of host reset operation, driver will flushout all IOs
> outstanding at driver level with "DID_RESET" result.
> To find which are all commands outstanding at the driver level,
> driver loops with smid starting from one to HBA queue depth and
> calls mpt3sas_scsih_scsi_lookup_get() to get scmd as shown below
>
> for (smid = 1; smid <= ioc->scsiio_depth; smid++) {
> scmd = mpt3sas_scsih_scsi_lookup_get(ioc, smid);
> if (!scmd)
> continue;
>
> But in mpt3sas_scsih_scsi_lookup_get() function, driver returns some
> scsi cmnds which are not outstanding at the driver level (possibly request
> is constructed at block layer since QUEUE_FLAG_QUIESCED is not set. Even if
> driver uses scsi_block_requests and scsi_unblock_requests, issue still
> persists as they will be just blocking further IO from scsi layer and
> not from block layer) and these commands are flushed with
> DID_RESET host bytes thus resulting into above kernel BUG.
Have you considered to call scsi_target_block() before flushing out pending
I/O and to call scsi_target_unblock() after flushing out pending I/O has
finished? I think that would be a much cleaner solution than the proposed
patch. The effect of scsi_target_block() is explained above
scsi_internal_device_block():
/**
* scsi_internal_device_block - try to transition to the SDEV_BLOCK state
* @sdev: device to block
*
* Pause SCSI command processing on the specified device and wait until all
* ongoing scsi_request_fn() / scsi_queue_rq() calls have finished. May sleep.
*
* Returns zero if successful or a negative error code upon failure.
*
* Note:
* This routine transitions the device to the SDEV_BLOCK state (which must be
* a legal transition). When the device is in this state, command processing
* is paused until the device leaves the SDEV_BLOCK state. See also
* scsi_internal_device_unblock().
*
* To do: avoid that scsi_send_eh_cmnd() calls queuecommand() after
* scsi_internal_device_block() has blocked a SCSI device and also
* remove the rport mutex lock and unlock calls from srp_queuecommand().
*/
Thanks,
Bart.
