Hello Bart, On Mon, 2023-01-16 at 09:48 -0800, Bart Van Assche wrote: > On 1/16/23 08:57, Martin Wilck wrote: > > Can we simply defer the scsi_device_put() to a workqueue? > > I'm concerned that would reintroduce a race condition when LLD kernel > modules are removed. I don't follow. Normally, alua_rtpg_queue() queues rtpg_work, and alua_rtpg_work() will be called from the work queue and will eventually call scsi_device_put() when the RTPG is finished. alua_rtpg_queue() only calls scsi_device_put() if queueing rtpg_work fails[*]. If we deferred this scsi_device_put() call to a work queue, what would be the difference (wrt a module_put() race condition) compared to the case where queue_delayed_work() succeeds? In both cases, scsi_device_put() would be called from a work queue. Given that alua_rtpg_queue() must take a reference to the scsi device for the case that queueing succeeds, and that alua_rtpg_queue() is sometimes called in atomic context, I think deferring the scsi_device_put() call is the only option we have. Thanks, Martin [*] or if queueing turns out to be unnecessary, in which case we could optimize away the scsi_device_get() call.
