On Tue, 2009-12-01 at 16:28 -0600, Michael Reed wrote: > > 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)? Well, no ... the sync on remove is preventing us removing a device whose async part is still running. That async part for libata includes pieces kicked off from the sd probe. > 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? The problem isn't removal per se ... it's the fact that remove can't complete until any async pieces remaining from probe have run. 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
