On Thu, 2017-06-15 at 19:10 -0500, Mike Christie wrote: > I think there is one small problem. Maybe not necessarily with this > patch but the change in it exposes it. > > If after we do a successful target_get_device a user app deletes the > backend device (does rmdir > /sys/kernel/config/target/core/fileio_1/somedevice), rmdir will will > return success immediately since we have a done a get above. The app > will then do rmdir on (/sys/kernel/config/target/core/fileio_1). > > The problem is that if the second rmdir on fileio_1 runs before > target_put_device below is done, then core_delete_hba will hit the > WARN_ON(hba->dev_count). Note that in this test target_depend_item will > fail because the first rmdir on "somedevice" has already succeeded. > > This does not happen without your patch, because the first rmdir on > /sys/kernel/config/target/core/fileio_1/somedevice would drop the > refcount to zero and the removing thread would either run > target_free_device before target_xcopy_locate_se_dev_e4 can grab the > g_device_mutex. Or, if target_xcopy_locate_se_dev_e4 grabs the > g_device_mutex firs, then target_depend_item will fail since because we > already deleting the device. Hello Mike, Had you noticed that due to patch "target: Fix a deadlock between the XCOPY code and iSCSI session shutdown" (commit 06546e842c24 in Nic's for-next branch) this patch is no longer necessary? Please let me know if you would need this patch anyway for another purpose than for fixing the deadlock explained in the description of this patch. Bart.-- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
