On Sun, Apr 22, 2012 at 10:15 AM, James Bottomley <James.Bottomley@xxxxxxxxxxxxxxxxxxxxx> wrote: > Async scan here means any scan in a different thread, right ... it just > has to be asynchronous relative to us? So that includes the manually > initiated ones and hotplug ones, doesn't it? [ resend since I notice this never hit the lists ] Hmm, well no I don't think so. This literally means the initial async scan, and the failure window is between when we skip the call to scsi_sysfs_add_sdev() (in scsi_add_lun() under the scan_mutex) and finally call scsi_sysfs_add_sdev() again via scsi_finish_async_scan(). I don't see how that fixes it because when we fail the sequence goes: mutex_lock(scan_mutex) starget->parent = end_device; scsi_add_lun() mutex_unlock(scan_mutex) device_del(end_device) mutex_lock(scan_mutex) device_add(starget) <crash> As far as I can see taking the scan_mutex in sas_rphy_remove() does not change this failure window. Unless I missed something? I am going to re-submit this patch as is with the proposed libsas batch for 3.5. -- Dan -- To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
