Re: [PATCH v2] scsi: Avoid that .queuecommand() gets called for a quiesced SCSI device

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

 



On Fri, 2018-03-16 at 10:40 -0700, Bart Van Assche wrote:
> @@ -1050,7 +1050,22 @@ static int scsi_send_eh_cmnd(struct scsi_cmnd
> *scmd, unsigned char *cmnd,
>  
>  	scsi_log_send(scmd);
>  	scmd->scsi_done = scsi_eh_done;
> -	rtn = shost->hostt->queuecommand(shost, scmd);
> +	mutex_lock(&sdev->state_mutex);
> +	while (sdev->sdev_state == SDEV_QUIESCE && timeleft > 0) {
> +		mutex_unlock(&sdev->state_mutex);
> +		SCSI_LOG_ERROR_RECOVERY(5, sdev_printk(KERN_DEBUG,
> sdev,
> +			"%s: state %d <> %d\n", __func__, sdev-
> >sdev_state,
> +			SDEV_QUIESCE));
> +		delay = min(timeleft, stall_for);
> +		timeleft -= delay;
> +		msleep(jiffies_to_msecs(delay));
> +		mutex_lock(&sdev->state_mutex);
> +	}

What's the point of this loop?  if you eliminate it, you still get
exactly the same msleep from the stall_for retry processing.

Plus I really don't think you want to call ->queuecommand() with the
state mutex held.

You don't even need to hold the state mutex to read sdev->state because
the read is atomic and the mutex doesn't mediate anything. The check to
queuecommand race is the same for every consumer.

James




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [SCSI Target Devel]     [Linux SCSI Target Infrastructure]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Linux IIO]     [Samba]     [Device Mapper]

  Powered by Linux