On Fri, 2018-03-30 at 15:07 +0530, Chaitra P B wrote:
diff --git a/drivers/scsi/mpt3sas/mpt3sas_ctl.c b/drivers/scsi/mpt3sas/mpt3sas_ctl.c index c1b17d6..2f27d5c 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_ctl.c +++ b/drivers/scsi/mpt3sas/mpt3sas_ctl.c @@ -590,7 +590,8 @@ _ctl_set_task_mid(struct MPT3SAS_ADAPTER *ioc, struct mpt3_ioctl_command *karg, struct scsiio_tracker *st; scmd = mpt3sas_scsih_scsi_lookup_get(ioc, smid);
if (!scmd)
if (scmd == NULL || scmd->device == NULL ||scmd->device->hostdata == NULL) continue;
Is _ctl_set_task_mid() always called from the I/O completion path? As Christoph already wrote, these checks do not make sense in the completion path.
@@ -600,6 +601,8 @@ _ctl_set_task_mid(struct MPT3SAS_ADAPTER *ioc, struct mpt3_ioctl_command *karg, if (priv_data->sas_target->handle != handle) continue; st = scsi_cmd_priv(scmd);
if ((!st) || (st->smid == 0))continue;
Since the I/O submission path guarantees that st->smid != 0, how could st->smid ever be zero in the I/O completion path?
diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c b/drivers/scsi/mpt3sas/mpt3sas_scsih.c index c9cce65..6b1aaa0 100644 --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c @@ -1465,7 +1465,7 @@ mpt3sas_scsih_scsi_lookup_get(struct MPT3SAS_ADAPTER *ioc, u16 smid) scmd = scsi_host_find_tag(ioc->shost, unique_tag); if (scmd) { st = scsi_cmd_priv(scmd);
if (st->cb_idx == 0xFF)
if ((!st) || (st->cb_idx == 0xFF) || (st->smid == 0)) scmd = NULL;@@ -4451,6 +4451,13 @@ _scsih_flush_running_cmds(struct MPT3SAS_ADAPTER *ioc) count++; _scsih_set_satl_pending(scmd, false); st = scsi_cmd_priv(scmd);
/** It may be possible that SCSI scmd got prepared by SML* but it has not issued to the driver, for these type of* scmd's don't do anything"*/if (st && st->smid == 0)continue;
This seems wrong to me. If a SCSI command has not been submitted to the firmware skipping it in this function will introduce a delay because the command will only be completed after it has timed out and after the SCSI error handler has finished its processing. I think it's better to complete the command from this function instead of waiting until for the SCSI error handler.
Bart.