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;
> if (lun != scmd->device->lun)
> 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;
> tm_request->TaskMID = cpu_to_le16(st->smid);
> found = 1;
> }
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.