Alan Stern wrote:
Anyhow, I'm not so concerned about releasing resources associated with the host. The LLD can handle that easily enough by first flagging the HBA as not accessible, then waiting for current I/O to terminate, then calling scsi_remove_host. The resources can be released any time after the current I/O is finished; it doesn't matter whether the host is removed before or after.
What do you mean by "flagging the HBA as not accessible"? In case you refer to scsi_block_requests(), this is taboo before any device is being removed from a host, or at least before high-level drivers are being detached from any device. scsi_remove_device() or --- if there are still devices present on a host and have high-level drivers attached --- scsi_remove_host() itself will cause I/O. If this I/O was blocked, scsi_remove_*() would be sitting in a deadlock.
The only resource that matters for this discussion is associated with the LLD itself, not with any of its hosts: the host template. Once the SCSI core has released all references to the template, it can't call the LLD any more. The problem is that the LLD has no way to know when all the references have been dropped. This suggests that the entire problem could be solved by adding a kref to struct scsi_host_template.
Why should the LLD care if the core might want to access it after the LLD made the prescribed API calls for host removal? It is the core's responsibility that it never enters the host again after these API calls were invoked. -- Stefan Richter -=====-=-=-= =--- --=== http://arcgraph.de/sr/ - : 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
