On 06/12/2013 08:28 AM, Bart Van Assche wrote: > + /* > + * It can occur that after fast_io_fail_tmo expired and before > + * dev_loss_tmo expired that the SCSI error handler has > + * offlined one or more devices. scsi_target_unblock() doesn't > + * change the state of these devices into running, so do that > + * explicitly. > + */ > + spin_lock_irq(shost->host_lock); > + __shost_for_each_device(sdev, shost) > + if (sdev->sdev_state == SDEV_OFFLINE) > + sdev->sdev_state = SDEV_RUNNING; > + spin_unlock_irq(shost->host_lock);
Is it possible for this to race with scsi_eh_offline_sdevs? Can it be looping over cmds offlining devices while this is looping over devices onlining them? It seems this can also happen for all transports/drivers. Maybe a a scsi eh/lib helper function that syncrhonizes with the scsi eh completion would be better. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
