On 1/17/23 01:28, Martin Wilck wrote:
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.
Hi Martin,
Before commit f93ed747e2c7 ("scsi: core: Release SCSI devices
synchronously") the SCSI device release code could continue running
asynchronously after the last module_put() call of the LLD associated
with the SCSI device.
Since commit f93ed747e2c7 it is guaranteed that freeing device memory
(scsi_device_dev_release()) has finished before the last LLD
module_put() call happens.
Do you perhaps plan to defer the scsi_device_put() calls in the ALUA
device handler to a workqueue?
Thanks,
Bart.
