James Bottomley wrote: > On Tue, 2009-12-01 at 15:45 -0600, Michael Reed wrote: >> Prevent delays and hangs due to sd_remove() waiting for the completion of >> async threads executing sd_probe_async of disks on unrelated host adapters. >> This patch executes every sd_probe_async in its own async domain allowing >> sd_remove() to wait for just the completion of the async thread associated with >> the scsi_disk being removed. > > This patch was thought of a while ago. Unfortunately, some of the > unrelated threads we end up waiting on are libata ones. you confine sd > to only its own probes, we end up unsynchronised with respect to libata > probes and we might cause ordering problems amongst the ata devices. > Isn't sd_remove() only concerned with the removal of a a single scsi_disk? Shouldn't libata use reference counting if it has is an issue with a scsi_disk being prematurely removed? Or is this a concern about "sd" naming? Or something else that I admittedly don't understand (but should)? I would truly like to better understand the issue. Would someone mind expanding upon the concern about ata ordering issues associated with the removal of a single scsi_disk? Thanks, Mike > James > > > -- > 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 -- 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
