On 7/14/22 10:32 AM, Mike Christie wrote: > On 7/12/22 5:29 PM, Bart Van Assche wrote: >> On 7/9/22 08:57, Mike Christie wrote: >>> If so, could we move what are doing in this patch down a level? Put the wait in >>> scsi_remove_target and wake in scsi_target_dev_release. Instead of a target_count >>> you have a scsi_target sdev_count. >>> >>> scsi_forget_host would then need to loop over the targets and do >>> scsi_target_remove on them instead of doing it at the scsi_device level. >> >> Hi Mike, >> >> Thanks for having taken a look. >> >> Could the approach outlined above have user-visible side effects? >> > > What kind of scenario are you thinking about? > > I think we would have similar behavior today for the target behavior: > > 1. With the current code, if there is no sysfs deletion going on and > scsi_remove_target's call to __scsi_remove_device is the one that blocks > on blk_cleanup_queue then the target removal would wait. > > > 2. With the current code we have: > > 1. syfs deletion runs scsi_remove_target -> scsi_remove_device and > that takes the scan_mutex. Meant sdev_store_delete -> scsi_remove_device > 2. scsi_remove_target passed the SDEV_DEL check and is calling Here I did mean scsi_remove_target. It's being called from something like the fc or iscsi layer's transport threads. > scsi_remove_device which is waiting on the scan_mutex. > > So here scsi_remove_target waits for the deletion similar to what I described > above. > > My suggestion just handles the case where > > 1. syfs deletion runs scsi_remove_target -> scsi_remove_device and > that takes the scan_mutex. Meant sdev_store_delete -> scsi_remove_device > > It then sets the state to SDEV_DEL. > > 2. scsi_remove_target runs and see the device is in the SDEV_DEL state. Here I did mean scsi_remove_target. It's being called from something like the fc or iscsi layer's transport threads. > It skips the device and then we return from scsi_remove_target without > having waited on that device's removal. > > > > >> A different approach has been selected for v4 of this patch series. Further feedback >> is welcome. >> >> Thanks, >> >> Bart. >
