Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
Mikhail, > The patch reverts changes done in qlt_schedule_sess_for_deletion() To > avoid spinlock recursion sess->vha->work_lock should be used instead > of ha->tgt.sess_lock, that can be locked in callers: qlt_reset() or > qlt_handle_login() Applied to 4.18/scsi-fixes. Thanks! -- Martin K. Petersen Oracle Linux Engineering
Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
> On Jun 13, 2018, at 9:20 AM, James Bottomley
> wrote:
>
> On Wed, 2018-06-13 at 16:13 +, Madhani, Himanshu wrote:
>>> On Jun 13, 2018, at 6:05 AM, Mikhail Malygin
>>> wrote:
>>>
>>> Here is the patch used for verification:
>>>
>>> [PATCH] scsi: qla2xxx: Fixup spinlock recursion in qla_target
>>>
>>> The patch reverts changes done in qlt_schedule_sess_for_deletion()
>>> To avoid spinlock recursion sess->vha->work_lock should be used
>>> instead of ha->tgt.sess_lock, that can be locked in
>>> callers: qlt_reset() or qlt_handle_login()
>>>
>>
>> Thanks for testing out the change.
>>
>>> Fixes: 1c6cacf4ea6c04 ("scsi: qla2xxx: Fixup locking for session
>>> deletion")
>>>
>>> Signed-off-by: Mikhail Malygin
>>
>> I want to see following tags for correctness
>>
>> Fixes: 1c6cacf4ea6c04 ("scsi: qla2xxx: Fixup locking for session
>> deletion”)
>> Cc: #4.17
>> Reported-by: Mikhail Malygin
>> Tested-by: Mikhail Malygin
>> Signed-off-by: Himanshu Madhani
>
> No on this last one: he can't add your signoff tag. The Signed-off-by:
> tags track the patch submission path and has meaning under the DCO, so
> if Mikhail sends it to you and you send it to the list (or you pick it
> off the list and resend it) *you* can add your signoff but not if it
> goes straight from Mikhail to the scsi tree (for this case we have an
> Acked-by: tag instead if that works for you?).
>
In that case Yes
Acked-by: Himanshu Madhani
> James
>
Thanks,
- Himanshu
Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
On Wed, 2018-06-13 at 16:13 +, Madhani, Himanshu wrote:
> > On Jun 13, 2018, at 6:05 AM, Mikhail Malygin
> > wrote:
> >
> > Here is the patch used for verification:
> >
> > [PATCH] scsi: qla2xxx: Fixup spinlock recursion in qla_target
> >
> > The patch reverts changes done in qlt_schedule_sess_for_deletion()
> > To avoid spinlock recursion sess->vha->work_lock should be used
> > instead of ha->tgt.sess_lock, that can be locked in
> > callers: qlt_reset() or qlt_handle_login()
> >
>
> Thanks for testing out the change.
>
> > Fixes: 1c6cacf4ea6c04 ("scsi: qla2xxx: Fixup locking for session
> > deletion")
> >
> > Signed-off-by: Mikhail Malygin
>
> I want to see following tags for correctness
>
> Fixes: 1c6cacf4ea6c04 ("scsi: qla2xxx: Fixup locking for session
> deletion”)
> Cc: #4.17
> Reported-by: Mikhail Malygin
> Tested-by: Mikhail Malygin
> Signed-off-by: Himanshu Madhani
No on this last one: he can't add your signoff tag. The Signed-off-by:
tags track the patch submission path and has meaning under the DCO, so
if Mikhail sends it to you and you send it to the list (or you pick it
off the list and resend it) *you* can add your signoff but not if it
goes straight from Mikhail to the scsi tree (for this case we have an
Acked-by: tag instead if that works for you?).
James
Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
> On Jun 13, 2018, at 6:05 AM, Mikhail Malygin wrote:
>
> Here is the patch used for verification:
>
> [PATCH] scsi: qla2xxx: Fixup spinlock recursion in qla_target
>
> The patch reverts changes done in qlt_schedule_sess_for_deletion()
> To avoid spinlock recursion sess->vha->work_lock should be used
> instead of ha->tgt.sess_lock, that can be locked in
> callers: qlt_reset() or qlt_handle_login()
>
Thanks for testing out the change.
> Fixes: 1c6cacf4ea6c04 ("scsi: qla2xxx: Fixup locking for session deletion")
>
> Signed-off-by: Mikhail Malygin
I want to see following tags for correctness
Fixes: 1c6cacf4ea6c04 ("scsi: qla2xxx: Fixup locking for session deletion”)
Cc: #4.17
Reported-by: Mikhail Malygin
Tested-by: Mikhail Malygin
Signed-off-by: Himanshu Madhani
> —
> drivers/scsi/qla2xxx/qla_target.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_target.c
> b/drivers/scsi/qla2xxx/qla_target.c
> index 025dc2d3f3de..032897e22e78 100644
> --- a/drivers/scsi/qla2xxx/qla_target.c
> +++ b/drivers/scsi/qla2xxx/qla_target.c
> @@ -1247,16 +1247,16 @@ void qlt_schedule_sess_for_deletion(struct fc_port
> *sess)
> return;
> }
>
> - spin_lock_irqsave(&ha->tgt.sess_lock, flags);
> if (sess->deleted == QLA_SESS_DELETED)
> sess->logout_on_delete = 0;
>
> + spin_lock_irqsave(&sess->vha->work_lock, flags);
> if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
> - spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
> + spin_unlock_irqrestore(&sess->vha->work_lock, flags);
> return;
> }
> sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
> - spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
> + spin_unlock_irqrestore(&sess->vha->work_lock, flags);
>
> sess->disc_state = DSC_DELETE_PEND;
>
> --
> 2.15.1
>
>
> From: Mikhail Malygin
> Sent: Wednesday, June 13, 2018 2:35 PM
> To: Madhani, Himanshu
> Cc: linux-scsi; Hannes Reinecke; Ivan Tchoub
> Subject: Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
>
> Hi Himanshu,
>
> I checked the same scenarios using work_lock instead of sess_lock, and I
> could not reproduce
> any of the issues mentioned before.
>
> Thanks,
> Mikhail
>
>
> From: Madhani, Himanshu
> Sent: Wednesday, June 13, 2018 12:29 AM
> To: Mikhail Malygin
> Cc: linux-scsi; Hannes Reinecke; Ivan Tchoub
> Subject: Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
>
> Hi Mikail,
>
>> On Jun 12, 2018, at 9:08 AM, m.maly...@yadro.com wrote:
>>
>> From: Mikhail Malygin
>>
>> This patch addresses issue causing spinlock recursion in qla_target.c:
>> 1. qlt_handle_login takes vha->hw->tgt.sess_lock, then calls
>> qlt_schedule_sess_for_deletion
>> where it tries to take spinlock again.
>
> We had posted patch to serialize session deletion with following patches
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=1ae634eb28533b82f9777a47c1ade44cb8c0182b
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=d8630bb95f46ea118dede63bd75533faa64f9612
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=d8630bb95f46ea118dede63bd75533faa64f9612
>
> However, this patch looks like introduced regression,
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=1c6cacf4ea6c04a58a0e3057f5ed60c24a4ffeff
>
> can you use work_lock as it was before the change and see if that helps with
> both issue 1 and 2.
>
> something like this
>
> diff --git a/drivers/scsi/qla2xxx/qla_target.c
> b/drivers/scsi/qla2xxx/qla_target.c
> index 7ed47800c660..d649f85d9657 100644
> --- a/drivers/scsi/qla2xxx/qla_target.c
> +++ b/drivers/scsi/qla2xxx/qla_target.c
> @@ -1239,16 +1239,16 @@ void qlt_schedule_sess_for_deletion(struct fc_port
> *sess)
> return;
> }
>
> - spin_lock_irqsave(&ha->tgt.sess_lock, flags);
> if (sess->deleted == QLA_SESS_DELETED)
> sess->logout_on_delete = 0;
>
> + spin_lock_irqsave(&sess->vha->work_lock, flags);
> if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
> - spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
> + spin_unlock_irqrestore(&sess->vha->work_lock, flags);
> return;
> }
> sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
Here is the patch used for verification:
[PATCH] scsi: qla2xxx: Fixup spinlock recursion in qla_target
The patch reverts changes done in qlt_schedule_sess_for_deletion()
To avoid spinlock recursion sess->vha->work_lock should be used
instead of ha->tgt.sess_lock, that can be locked in
callers: qlt_reset() or qlt_handle_login()
Fixes: 1c6cacf4ea6c04 ("scsi: qla2xxx: Fixup locking for session deletion")
Signed-off-by: Mikhail Malygin
---
drivers/scsi/qla2xxx/qla_target.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_target.c
b/drivers/scsi/qla2xxx/qla_target.c
index 025dc2d3f3de..032897e22e78 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -1247,16 +1247,16 @@ void qlt_schedule_sess_for_deletion(struct fc_port
*sess)
return;
}
- spin_lock_irqsave(&ha->tgt.sess_lock, flags);
if (sess->deleted == QLA_SESS_DELETED)
sess->logout_on_delete = 0;
+ spin_lock_irqsave(&sess->vha->work_lock, flags);
if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
- spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
+ spin_unlock_irqrestore(&sess->vha->work_lock, flags);
return;
}
sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
- spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
+ spin_unlock_irqrestore(&sess->vha->work_lock, flags);
sess->disc_state = DSC_DELETE_PEND;
--
2.15.1
From: Mikhail Malygin
Sent: Wednesday, June 13, 2018 2:35 PM
To: Madhani, Himanshu
Cc: linux-scsi; Hannes Reinecke; Ivan Tchoub
Subject: Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
Hi Himanshu,
I checked the same scenarios using work_lock instead of sess_lock, and I could
not reproduce
any of the issues mentioned before.
Thanks,
Mikhail
From: Madhani, Himanshu
Sent: Wednesday, June 13, 2018 12:29 AM
To: Mikhail Malygin
Cc: linux-scsi; Hannes Reinecke; Ivan Tchoub
Subject: Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
Hi Mikail,
> On Jun 12, 2018, at 9:08 AM, m.maly...@yadro.com wrote:
>
> From: Mikhail Malygin
>
> This patch addresses issue causing spinlock recursion in qla_target.c:
> 1. qlt_handle_login takes vha->hw->tgt.sess_lock, then calls
> qlt_schedule_sess_for_deletion
> where it tries to take spinlock again.
We had posted patch to serialize session deletion with following patches
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=1ae634eb28533b82f9777a47c1ade44cb8c0182b
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=d8630bb95f46ea118dede63bd75533faa64f9612
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=d8630bb95f46ea118dede63bd75533faa64f9612
However, this patch looks like introduced regression,
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=1c6cacf4ea6c04a58a0e3057f5ed60c24a4ffeff
can you use work_lock as it was before the change and see if that helps with
both issue 1 and 2.
something like this
diff --git a/drivers/scsi/qla2xxx/qla_target.c
b/drivers/scsi/qla2xxx/qla_target.c
index 7ed47800c660..d649f85d9657 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -1239,16 +1239,16 @@ void qlt_schedule_sess_for_deletion(struct fc_port
*sess)
return;
}
- spin_lock_irqsave(&ha->tgt.sess_lock, flags);
if (sess->deleted == QLA_SESS_DELETED)
sess->logout_on_delete = 0;
+ spin_lock_irqsave(&sess->vha->work_lock, flags);
if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
- spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
+ spin_unlock_irqrestore(&sess->vha->work_lock, flags);
return;
}
sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
- spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
+ spin_unlock_irqrestore(&sess->vha->work_lock, flags);
sess->disc_state = DSC_DELETE_PEND;
> 2. qlt_reset takes the same lock, then calls qlt_schedule_sess_for_deleteion
> via qlt_clear_tgt_db
>
> Stacktrace for qlt_handle_login
>
> BUG: spinlock lockup suspected on CPU#0, swapper/0/0
> lock: 0xc0c07aa8bec0, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE NX
> 4.4.132-ttln.24-debug #1
> Call Trace:
> [c0dfff6d7830] [c08060c0] dump_stack+0xb0/0xf0 (unreliable)
> [c0dfff6d7870] [c07ff6ec] spin_dump+0xa8/0xc4
> [c0dfff6d78e0] [c0128320] do_raw_spin_lock+0x140/0x1d0
> [c0dfff6d7920] [c07f7354] _raw_spin_lock_irqsa
Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
Hi Himanshu,
I checked the same scenarios using work_lock instead of sess_lock, and I could
not reproduce
any of the issues mentioned before.
Thanks,
Mikhail
From: Madhani, Himanshu
Sent: Wednesday, June 13, 2018 12:29 AM
To: Mikhail Malygin
Cc: linux-scsi; Hannes Reinecke; Ivan Tchoub
Subject: Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
Hi Mikail,
> On Jun 12, 2018, at 9:08 AM, m.maly...@yadro.com wrote:
>
> From: Mikhail Malygin
>
> This patch addresses issue causing spinlock recursion in qla_target.c:
> 1. qlt_handle_login takes vha->hw->tgt.sess_lock, then calls
> qlt_schedule_sess_for_deletion
> where it tries to take spinlock again.
We had posted patch to serialize session deletion with following patches
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=1ae634eb28533b82f9777a47c1ade44cb8c0182b
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=d8630bb95f46ea118dede63bd75533faa64f9612
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=d8630bb95f46ea118dede63bd75533faa64f9612
However, this patch looks like introduced regression,
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=1c6cacf4ea6c04a58a0e3057f5ed60c24a4ffeff
can you use work_lock as it was before the change and see if that helps with
both issue 1 and 2.
something like this
diff --git a/drivers/scsi/qla2xxx/qla_target.c
b/drivers/scsi/qla2xxx/qla_target.c
index 7ed47800c660..d649f85d9657 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -1239,16 +1239,16 @@ void qlt_schedule_sess_for_deletion(struct fc_port
*sess)
return;
}
- spin_lock_irqsave(&ha->tgt.sess_lock, flags);
if (sess->deleted == QLA_SESS_DELETED)
sess->logout_on_delete = 0;
+ spin_lock_irqsave(&sess->vha->work_lock, flags);
if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
- spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
+ spin_unlock_irqrestore(&sess->vha->work_lock, flags);
return;
}
sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
- spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
+ spin_unlock_irqrestore(&sess->vha->work_lock, flags);
sess->disc_state = DSC_DELETE_PEND;
> 2. qlt_reset takes the same lock, then calls qlt_schedule_sess_for_deleteion
> via qlt_clear_tgt_db
>
> Stacktrace for qlt_handle_login
>
> BUG: spinlock lockup suspected on CPU#0, swapper/0/0
> lock: 0xc0c07aa8bec0, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE NX
> 4.4.132-ttln.24-debug #1
> Call Trace:
> [c0dfff6d7830] [c08060c0] dump_stack+0xb0/0xf0 (unreliable)
> [c0dfff6d7870] [c07ff6ec] spin_dump+0xa8/0xc4
> [c0dfff6d78e0] [c0128320] do_raw_spin_lock+0x140/0x1d0
> [c0dfff6d7920] [c07f7354] _raw_spin_lock_irqsave+0x34/0x50
> [c0dfff6d7950] [d0001edf3220]
> qlt_schedule_sess_for_deletion+0x90/0x250 [qla2xxx]
> [c0dfff6d79c0] [d0001edf6b08]
> qlt_find_sess_invalidate_other+0x1d8/0x230 [qla2xxx]
> [c0dfff6d7a70] [d0001edf710c] qlt_handle_login+0x5ac/0x760 [qla2xxx]
> [c0dfff6d7b10] [d0001edf7ccc] qlt_handle_imm_notify+0xa0c/0x10b0
> [qla2xxx]
> [c0dfff6d7c00] [d0001edf85f0] qlt_24xx_atio_pkt+0x280/0x400 [qla2xxx]
> [c0dfff6d7ca0] [d0001edfa9d8] qlt_24xx_process_atio_queue+0x368/0x7d0
> [qla2xxx]
> [c0dfff6d7d80] [d0001edfb898] qla83xx_msix_atio_q+0x58/0x90 [qla2xxx]
> [c0dfff6d7dc0] [c0133cd0] __handle_irq_event_percpu+0xa0/0x2f0
> [c0dfff6d7e80] [c0133f5c] handle_irq_event_percpu+0x3c/0x90
> [c0dfff6d7ec0] [c0134018] handle_irq_event+0x68/0xb0
> [c0dfff6d7f00] [c0139278] handle_fasteoi_irq+0xf8/0x260
> [c0dfff6d7f40] [c0132e80] generic_handle_irq+0x50/0x80
> [c0dfff6d7f60] [c0014c44] __do_irq+0x84/0x1d0
> [c0dfff6d7f90] [c0027924] call_do_irq+0x14/0x24
> [c0f13a20] [c0014e30] do_IRQ+0xa0/0x120
> [c0f13a70] [c0002694] hardware_interrupt_common+0x114/0x180
> --- interrupt: 501 at snooze_loop+0xc4/0x1a0
> LR = snooze_loop+0x16c/0x1a0
> [c0f13d60] [c063b41c] nap_loop+0x5c/0x120 (unreliable)
> [c0f13da0] [c0637f9c] cpuidle_enter_state+0xbc/0x3d0
> [c0f13e00] [c011db10] call_cpuidle+0x50/0x80
> [c0f13e20] [c011e138] cpu_startup_entry+0x388/0x490
> [c0f13ee0] [c000c260] rest_init+0xb0/0xd0
> [c0f13f00] [c0aa4070] start_kernel+0x55c/0x578
> [c0f13f90] [
Re: [PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
Hi Mikail,
> On Jun 12, 2018, at 9:08 AM, m.maly...@yadro.com wrote:
>
> From: Mikhail Malygin
>
> This patch addresses issue causing spinlock recursion in qla_target.c:
> 1. qlt_handle_login takes vha->hw->tgt.sess_lock, then calls
> qlt_schedule_sess_for_deletion
> where it tries to take spinlock again.
We had posted patch to serialize session deletion with following patches
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=1ae634eb28533b82f9777a47c1ade44cb8c0182b
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=d8630bb95f46ea118dede63bd75533faa64f9612
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=d8630bb95f46ea118dede63bd75533faa64f9612
However, this patch looks like introduced regression,
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=1c6cacf4ea6c04a58a0e3057f5ed60c24a4ffeff
can you use work_lock as it was before the change and see if that helps with
both issue 1 and 2.
something like this
diff --git a/drivers/scsi/qla2xxx/qla_target.c
b/drivers/scsi/qla2xxx/qla_target.c
index 7ed47800c660..d649f85d9657 100644
--- a/drivers/scsi/qla2xxx/qla_target.c
+++ b/drivers/scsi/qla2xxx/qla_target.c
@@ -1239,16 +1239,16 @@ void qlt_schedule_sess_for_deletion(struct fc_port
*sess)
return;
}
- spin_lock_irqsave(&ha->tgt.sess_lock, flags);
if (sess->deleted == QLA_SESS_DELETED)
sess->logout_on_delete = 0;
+ spin_lock_irqsave(&sess->vha->work_lock, flags);
if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
- spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
+ spin_unlock_irqrestore(&sess->vha->work_lock, flags);
return;
}
sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
- spin_unlock_irqrestore(&ha->tgt.sess_lock, flags);
+ spin_unlock_irqrestore(&sess->vha->work_lock, flags);
sess->disc_state = DSC_DELETE_PEND;
> 2. qlt_reset takes the same lock, then calls qlt_schedule_sess_for_deleteion
> via qlt_clear_tgt_db
>
> Stacktrace for qlt_handle_login
>
> BUG: spinlock lockup suspected on CPU#0, swapper/0/0
> lock: 0xc0c07aa8bec0, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE NX
> 4.4.132-ttln.24-debug #1
> Call Trace:
> [c0dfff6d7830] [c08060c0] dump_stack+0xb0/0xf0 (unreliable)
> [c0dfff6d7870] [c07ff6ec] spin_dump+0xa8/0xc4
> [c0dfff6d78e0] [c0128320] do_raw_spin_lock+0x140/0x1d0
> [c0dfff6d7920] [c07f7354] _raw_spin_lock_irqsave+0x34/0x50
> [c0dfff6d7950] [d0001edf3220]
> qlt_schedule_sess_for_deletion+0x90/0x250 [qla2xxx]
> [c0dfff6d79c0] [d0001edf6b08]
> qlt_find_sess_invalidate_other+0x1d8/0x230 [qla2xxx]
> [c0dfff6d7a70] [d0001edf710c] qlt_handle_login+0x5ac/0x760 [qla2xxx]
> [c0dfff6d7b10] [d0001edf7ccc] qlt_handle_imm_notify+0xa0c/0x10b0
> [qla2xxx]
> [c0dfff6d7c00] [d0001edf85f0] qlt_24xx_atio_pkt+0x280/0x400 [qla2xxx]
> [c0dfff6d7ca0] [d0001edfa9d8] qlt_24xx_process_atio_queue+0x368/0x7d0
> [qla2xxx]
> [c0dfff6d7d80] [d0001edfb898] qla83xx_msix_atio_q+0x58/0x90 [qla2xxx]
> [c0dfff6d7dc0] [c0133cd0] __handle_irq_event_percpu+0xa0/0x2f0
> [c0dfff6d7e80] [c0133f5c] handle_irq_event_percpu+0x3c/0x90
> [c0dfff6d7ec0] [c0134018] handle_irq_event+0x68/0xb0
> [c0dfff6d7f00] [c0139278] handle_fasteoi_irq+0xf8/0x260
> [c0dfff6d7f40] [c0132e80] generic_handle_irq+0x50/0x80
> [c0dfff6d7f60] [c0014c44] __do_irq+0x84/0x1d0
> [c0dfff6d7f90] [c0027924] call_do_irq+0x14/0x24
> [c0f13a20] [c0014e30] do_IRQ+0xa0/0x120
> [c0f13a70] [c0002694] hardware_interrupt_common+0x114/0x180
> --- interrupt: 501 at snooze_loop+0xc4/0x1a0
>LR = snooze_loop+0x16c/0x1a0
> [c0f13d60] [c063b41c] nap_loop+0x5c/0x120 (unreliable)
> [c0f13da0] [c0637f9c] cpuidle_enter_state+0xbc/0x3d0
> [c0f13e00] [c011db10] call_cpuidle+0x50/0x80
> [c0f13e20] [c011e138] cpu_startup_entry+0x388/0x490
> [c0f13ee0] [c000c260] rest_init+0xb0/0xd0
> [c0f13f00] [c0aa4070] start_kernel+0x55c/0x578
> [c0f13f90] [c0008e6c] start_here_common+0x20/0xb4
> nvme nvme0: I/O 782 QID 9 timeout, completion polled
> nvme nvme0: I/O 99 QID 12 timeout, completion polled
> nvme nvme0: I/O 925 QID 4 timeout, completio
>
>
> Stacktrace for qlt_reset:
>
> BUG: spinlock recursion on CPU#0, swapper/0/0
> lock: 0xc0207d5ffec0, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0
> CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE NX
> 4.4.132-ttln.25-debug #1
> Call Trace:
> [c03fff71b8d0] [c08060c0] dump_stack+0xb0/0xf0 (unreliable)
> [c03fff71b910] [c07ff6ec] spin_dump+0xa8
[PATCH v2] scsi: qla2xxx: Spinlock recursion in qla_target
From: Mikhail Malygin This patch addresses issue causing spinlock recursion in qla_target.c: 1. qlt_handle_login takes vha->hw->tgt.sess_lock, then calls qlt_schedule_sess_for_deletion where it tries to take spinlock again. 2. qlt_reset takes the same lock, then calls qlt_schedule_sess_for_deleteion via qlt_clear_tgt_db Stacktrace for qlt_handle_login BUG: spinlock lockup suspected on CPU#0, swapper/0/0 lock: 0xc0c07aa8bec0, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE NX 4.4.132-ttln.24-debug #1 Call Trace: [c0dfff6d7830] [c08060c0] dump_stack+0xb0/0xf0 (unreliable) [c0dfff6d7870] [c07ff6ec] spin_dump+0xa8/0xc4 [c0dfff6d78e0] [c0128320] do_raw_spin_lock+0x140/0x1d0 [c0dfff6d7920] [c07f7354] _raw_spin_lock_irqsave+0x34/0x50 [c0dfff6d7950] [d0001edf3220] qlt_schedule_sess_for_deletion+0x90/0x250 [qla2xxx] [c0dfff6d79c0] [d0001edf6b08] qlt_find_sess_invalidate_other+0x1d8/0x230 [qla2xxx] [c0dfff6d7a70] [d0001edf710c] qlt_handle_login+0x5ac/0x760 [qla2xxx] [c0dfff6d7b10] [d0001edf7ccc] qlt_handle_imm_notify+0xa0c/0x10b0 [qla2xxx] [c0dfff6d7c00] [d0001edf85f0] qlt_24xx_atio_pkt+0x280/0x400 [qla2xxx] [c0dfff6d7ca0] [d0001edfa9d8] qlt_24xx_process_atio_queue+0x368/0x7d0 [qla2xxx] [c0dfff6d7d80] [d0001edfb898] qla83xx_msix_atio_q+0x58/0x90 [qla2xxx] [c0dfff6d7dc0] [c0133cd0] __handle_irq_event_percpu+0xa0/0x2f0 [c0dfff6d7e80] [c0133f5c] handle_irq_event_percpu+0x3c/0x90 [c0dfff6d7ec0] [c0134018] handle_irq_event+0x68/0xb0 [c0dfff6d7f00] [c0139278] handle_fasteoi_irq+0xf8/0x260 [c0dfff6d7f40] [c0132e80] generic_handle_irq+0x50/0x80 [c0dfff6d7f60] [c0014c44] __do_irq+0x84/0x1d0 [c0dfff6d7f90] [c0027924] call_do_irq+0x14/0x24 [c0f13a20] [c0014e30] do_IRQ+0xa0/0x120 [c0f13a70] [c0002694] hardware_interrupt_common+0x114/0x180 --- interrupt: 501 at snooze_loop+0xc4/0x1a0 LR = snooze_loop+0x16c/0x1a0 [c0f13d60] [c063b41c] nap_loop+0x5c/0x120 (unreliable) [c0f13da0] [c0637f9c] cpuidle_enter_state+0xbc/0x3d0 [c0f13e00] [c011db10] call_cpuidle+0x50/0x80 [c0f13e20] [c011e138] cpu_startup_entry+0x388/0x490 [c0f13ee0] [c000c260] rest_init+0xb0/0xd0 [c0f13f00] [c0aa4070] start_kernel+0x55c/0x578 [c0f13f90] [c0008e6c] start_here_common+0x20/0xb4 nvme nvme0: I/O 782 QID 9 timeout, completion polled nvme nvme0: I/O 99 QID 12 timeout, completion polled nvme nvme0: I/O 925 QID 4 timeout, completio Stacktrace for qlt_reset: BUG: spinlock recursion on CPU#0, swapper/0/0 lock: 0xc0207d5ffec0, .magic: dead4ead, .owner: swapper/0/0, .owner_cpu: 0 CPU: 0 PID: 0 Comm: swapper/0 Tainted: G OE NX 4.4.132-ttln.25-debug #1 Call Trace: [c03fff71b8d0] [c08060c0] dump_stack+0xb0/0xf0 (unreliable) [c03fff71b910] [c07ff6ec] spin_dump+0xa8/0xc4 [c03fff71b980] [c01283a4] do_raw_spin_lock+0x1c4/0x1d0 [c03fff71b9c0] [c07f7354] _raw_spin_lock_irqsave+0x34/0x50 [c03fff71b9f0] [d000128933b4] qlt_schedule_sess_for_deletion+0x44/0x80 [qla2xxx] [c03fff71ba30] [d00012893454] qlt_clear_tgt_db+0x64/0x90 [qla2xxx] [c03fff71ba60] [d00012893604] qlt_reset+0x184/0x1f0 [qla2xxx] [c03fff71bb10] [d00012897a2c] qlt_handle_imm_notify+0x74c/0x10b0 [qla2xxx] [c03fff71bc00] [d00012898610] qlt_24xx_atio_pkt+0x280/0x400 [qla2xxx] [c03fff71bca0] [d0001289a9f8] qlt_24xx_process_atio_queue+0x368/0x7d0 [qla2xxx] [c03fff71bd80] [d0001289b8b8] qla83xx_msix_atio_q+0x58/0x90 [qla2xxx] [c03fff71bdc0] [c0133cd0] __handle_irq_event_percpu+0xa0/0x2f0 [c03fff71be80] [c0133f5c] handle_irq_event_percpu+0x3c/0x90 [c03fff71bec0] [c0134018] handle_irq_event+0x68/0xb0 [c03fff71bf00] [c0139278] handle_fasteoi_irq+0xf8/0x260 [c03fff71bf40] [c0132e80] generic_handle_irq+0x50/0x80 [c03fff71bf60] [c0014c44] __do_irq+0x84/0x1d0 [c03fff71bf90] [c0027924] call_do_irq+0x14/0x24 [c0f13a40] [c0014e30] do_IRQ+0xa0/0x120 [c0f13a90] [c0002694] hardware_interrupt_common+0x114/0x180 --- interrupt: 501 at arch_local_irq_restore+0x5c/0x90 LR = arch_local_irq_restore+0x40/0x90 [c0f13d80] [c0f1] init_thread_union+0x0/0x2000 (unreliable) [c0f13da0] [c0637fec] cpuidle_enter_state+0x10c/0x3d0 [c0f13e00] [c011db10] call_cpuidle+0x50/0x80 [c0f13e20] [c011e138] cpu_startup_entry+0x388/0x490 [c0f13ee0] [c000c260] rest_init+0xb0/0xd0 [c0f13f00] [c0aa4070] start_kernel+0x55c/0x578 [c0f13f90] [c0008e6c] start_here_common+0x20/0xb4 Steps to reproduce: 1. C
