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

[Bart Van Assche <bvanassche@acm.org>]

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.