Message ID | 1335114924.13208.27.camel@dabdike.lan |
---|---|
State | Not Applicable |
Delegated to: | David Miller |
Headers | show |
On Sun, Apr 22, 2012 at 10:15 AM, James Bottomley <James.Bottomley@hansenpartnership.com> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/drivers/scsi/scsi_transport_sas.c b/drivers/scsi/scsi_transport_sas.c index f7565fc..c89bba6 100644 --- a/drivers/scsi/scsi_transport_sas.c +++ b/drivers/scsi/scsi_transport_sas.c @@ -1669,7 +1669,9 @@ sas_rphy_remove(struct sas_rphy *rphy) switch (rphy->identify.device_type) { case SAS_END_DEVICE: + mutex_lock(&shost->scan_mutex); scsi_remove_target(dev); + mutex_unlock(&shost->scan_mutex); break; case SAS_EDGE_EXPANDER_DEVICE: case SAS_FANOUT_EXPANDER_DEVICE: