On 10/27/2016 02:36 AM, Sagi Grimberg wrote:
The solution I prefer is to modify the SCSI scanning code such that
the scan_mutex is only held while performing the actual LUN scanning
and while ensuring that no SCSI device has been created yet for a
certain LUN number but not while the Linux device and its sysfs
attributes are created. Since that approach would require extensive
changes in the SCSI scanning code, another approach has been chosen,
namely to make self-removal asynchronous. This patch avoids that
self-removal triggers the following deadlock:
Is this a real deadlock? or just a lockdep complaint?
Wouldn't making scsi_remove_device() taking single depth
mutex_lock_nested suffice here?
Hello Sagi,
It's a real deadlock, and I can trigger it relatively easy by deleting a
SCSI device that is managed by the dm-multipath driver.
Bart.
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
