On Fri, 13 Dec 2013, James Bottomley wrote: > > > I wasn't clear on the reason for that problem. Does it also arise from > > > late device_del for scsi_target? I could try to change the way that > > > works, if anybody (Hans?) would like to test it. > > > > While the recent sysfs changes made this issue more visible, Greg > > wants to make sure that devices are removed from leaf up in all cases > > and keep the warning to ensure that. Would there be a way fix SCSI > > removal ordering? > > Could someone analyse the actual problem? We're quite careful even on > host remove to iterate and remove all the devices, then targets, then > host (and allied transport objects). Which removal is inverted?
The scsi_host is removed before the scsi_target. The reason is that scsi_remove_host() calls device_del(&shost->shost_gendev) directly, but scsi_target_reap_usercontext() doesn't call device_del(&starget->dev) until it gets invoked (indirectly) from scsi_device_dev_release_usercontext(), by way of scsi_target_reap(). Thus, the host gets removed from visibility at the appropriate time, but the target remains until all the scsi_devices beneath it are not only removed from visibility but also released (their refcounts drop to 0). This can occur much later if, for example, a scsi_device holds a mounted filesystem. The scsi_host and scsi_device are removed when the underlying USB device is unplugged. But the scsi_device isn't released, and hence the scsi_target isn't removed, until the filesystem is unmounted. Broadly speaking, the correct approach would be to call scsi_target_reap() from __scsi_remove_device() instead of from scsi_device_dev_release_usercontext(). Alan Stern -- 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
