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. 2. scsi_remove_target passed the SDEV_DEL check and is calling 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. It then sets the state to SDEV_DEL. 2. scsi_remove_target runs and see the device is in the SDEV_DEL state. 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.
