Re: kernel BUG scsi_dh_alua sleeping from invalid context && kernel WARNING do not call blocking ops when !TASK_RUNNING

[Martin Wilck <mwilck@suse.com>]

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.