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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Kernel Development]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Info]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Linux Media]     [Device Mapper]

  Powered by Linux