Re: [PATCH 12/12] scsi_transport_sas: fix delete vs scan race

[Dan Williams <dan.j.williams@xxxxxxxxx>]

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-scsi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html