Re: [PATCH 03/15] mpt3sas: Add sanity checks for scsi tracker before accessing it.
From: Bart Van Assche <hidden>
Date: 2018-03-30 15:54:47
Also in:
linux-scsi
On Fri, 2018-03-30 at 15:07 +0530, Chaitra P B wrote:
quoted hunk ↗ jump to hunk
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.
quoted hunk ↗ jump to hunk
@@ -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?
quoted hunk ↗ jump to hunk
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.