On Fri, Jun 22, 2018 at 02:54:49PM -0700, Bart Van Assche wrote:
> In the scsi_transport_srp implementation it cannot be avoided to
> iterate over a klist from atomic context when using the legacy
> block layer instead of blk-mq. Hence this patch that makes it safe
> to use klists in atomic context. This patch avoids that lockdep
> reports the following:
>
> WARNING: SOFTIRQ-safe -> SOFTIRQ-unsafe lock order detected
> Possible interrupt unsafe locking scenario:
>
> CPU0 CPU1
> ---- ----
> lock(&(&k->k_lock)->rlock);
> local_irq_disable();
> lock(&(&q->__queue_lock)->rlock);
> lock(&(&k->k_lock)->rlock);
> <Interrupt>
> lock(&(&q->__queue_lock)->rlock);
>
> stack backtrace:
> Workqueue: kblockd blk_timeout_work
> Call Trace:
> dump_stack+0xa4/0xf5
> check_usage+0x6e6/0x700
> __lock_acquire+0x185d/0x1b50
> lock_acquire+0xd2/0x260
> _raw_spin_lock+0x32/0x50
> klist_next+0x47/0x190
> device_for_each_child+0x8e/0x100
> srp_timed_out+0xaf/0x1d0 [scsi_transport_srp]
> scsi_times_out+0xd4/0x410 [scsi_mod]
> blk_rq_timed_out+0x36/0x70
> blk_timeout_work+0x1b5/0x220
> process_one_work+0x4fe/0xad0
> worker_thread+0x63/0x5a0
> kthread+0x1c1/0x1e0
> ret_from_fork+0x24/0x30
>
> See also commit c9ddf73476ff ("scsi: scsi_transport_srp: Fix shost
> to rport translation").
>
> Signed-off-by: Bart Van Assche <[email protected]>
> Cc: Martin K. Petersen <[email protected]>
> Cc: James Bottomley <[email protected]>
> ---
> lib/klist.c | 10 ++++++----
> 1 file changed, 6 insertions(+), 4 deletions(-)
No objection from me:
Acked-by: Greg Kroah-Hartman <[email protected]>
This should probably go through the scsi tree, right?
thanks,
greg k-h
