Re: [PATCH 03/15] mpt3sas: Add sanity checks for scsi tracker before accessing it.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.









[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]