On 06/24/2013 02:19 PM, James Bottomley wrote: > On Wed, 2013-06-12 at 14:55 +0200, Bart Van Assche wrote: >> A SCSI LLD may start cleaning up host resources as soon as >> scsi_remove_host() returns. These host resources may be needed by >> the LLD in an implementation of one of the eh_* functions. So if >> one of the eh_* functions is in progress when scsi_remove_host() >> is invoked, wait until the eh_* function has finished. Also, do >> not invoke any of the eh_* functions after scsi_remove_host() has >> started. > > We already have state guards for this, don't we? That's the > SHOST_*_RECOVERY ones. When eh functions are active, the host > transitions to a recovery state, so the wait could just wait on that > state rather than implement an open coded counting semaphore. > That seems better. For the sg_reset_provider case we just would have to also wait on the tmf_in_progress bit. I think I used all my credits messing up reviewing this patchset. > However, what's the reasoning behind wanting to do this? In theory all > necessary resources for the eh thread should only be freed in the > release callback. That means they aren't freed until all error recovery > completes. > I think it makes it easier to handle cleanup of driver resources needed for aborts/resets for some drivers. If after host removal, the scsi eh can call into the driver after scsi_remove_host is called then we have to set some internal bits to fail future eh callback calls and handle waiting on or flushing running eh operations. If we know that after scsi_host_remove is called the eh callbacks will not be running and will not be called we can just free the driver resources. For iscsi and I think drivers that do scsi_remove_target it would be helpful to have something similar at the target level. -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
