On Tue, 2023-01-17 at 10:50 -0800, Bart Van Assche wrote:
> 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?
Yes, that was my suggestion. Just defer the scsi_device_put() call in
alua_rtpg_queue() in the case where the actual RTPG handler is not
queued. I won't have time for that before next week though.
Martin
