RE: [PATCH] mpt3sas: Fix calltrace observed while running IO & host reset
Bart,
When host reset is issued from application, through ioctl reset handler
_ctl_do_reset() -> mpt3sas_base_hard_reset_handler() sets
“ioc->shost_recovery” flag.
If “ioc->shost_recovery” flag is set then driver will return all the
incoming SCSI cmds with “SCSI_MLQUEUE_HOST_BUSY” in the scsih_qcmd(). And
hence no new request gets processed by the driver until the reset completes,
which guarantees that the smid won't change.
Thanks,
Chaitra
-Original Message-
From: Bart Van Assche [mailto:bart.vanass...@wdc.com]
Sent: Tuesday, June 12, 2018 8:54 PM
To: chaitra.basa...@broadcom.com; linux-scsi@vger.kernel.org
Cc: sathya.prak...@broadcom.com; suganath-prabu.subram...@broadcom.com;
sreekanth.re...@broadcom.com
Subject: Re: [PATCH] mpt3sas: Fix calltrace observed while running IO & host
reset
On Tue, 2018-06-12 at 09:17 -0400, Chaitra P B wrote:
> diff --git a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> index 23902ad..96e523a 100644
> --- a/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> +++ b/drivers/scsi/mpt3sas/mpt3sas_scsih.c
> @@ -1489,7 +1489,7 @@ struct scsi_cmnd *
> scmd = scsi_host_find_tag(ioc->shost, unique_tag);
> if (scmd) {
> st = scsi_cmd_priv(scmd);
> - if (st->cb_idx == 0xFF)
> + if (st->cb_idx == 0xFF || st->smid == 0)
> scmd = NULL;
> }
> }
What guarantees that st->smid won't change after it has been checked and
before scmd is used?
Thanks,
Bart.
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(>tgt.sess_lock, flags);
if (sess->deleted == QLA_SESS_DELETED)
sess->logout_on_delete = 0;
+ spin_lock_irqsave(>vha->work_lock, flags);
if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
- spin_unlock_irqrestore(>tgt.sess_lock, flags);
+ spin_unlock_irqrestore(>vha->work_lock, flags);
return;
}
sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
- spin_unlock_irqrestore(>tgt.sess_lock, flags);
+ spin_unlock_irqrestore(>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
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(>tgt.sess_lock, flags);
if (sess->deleted == QLA_SESS_DELETED)
sess->logout_on_delete = 0;
+ spin_lock_irqsave(>vha->work_lock, flags);
if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
- spin_unlock_irqrestore(>tgt.sess_lock, flags);
+ spin_unlock_irqrestore(>vha->work_lock, flags);
return;
}
sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
- spin_unlock_irqrestore(>tgt.sess_lock, flags);
+ spin_unlock_irqrestore(>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(>tgt.sess_lock, flags);
if (sess->deleted == QLA_SESS_DELETED)
sess->logout_on_delete = 0;
+ spin_lock_irqsave(>vha->work_lock, flags);
if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
- spin_unlock_irqrestore(>tgt.sess_lock, flags);
+ spin_unlock_irqrestore(>vha->work_lock, flags);
return;
}
sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
- spin_unlock_irqrestore(>tgt.sess_lock, flags);
+ spin_unlock_irqrestore(>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]
>
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 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] mpt3sas: Fix calltrace observed while running IO & host reset
On Wed, 2018-06-13 at 15:46 +0530, Chaitra Basappa wrote: > When host reset is issued from application, through ioctl reset handler > _ctl_do_reset() -> mpt3sas_base_hard_reset_handler() sets > “ioc->shost_recovery” flag. > If “ioc->shost_recovery” flag is set then driver will return all the > incoming SCSI cmds with “SCSI_MLQUEUE_HOST_BUSY” in the scsih_qcmd(). And > hence no new request gets processed by the driver until the reset completes, > which guarantees that the smid won't change. Hello Chaitra, The patch at the start of this e-mail thread checks whether st->smid is zero. That check could only be useful if there would be code in the mpt3sas driver that clears that field upon command completion. However, I haven't found any such code in the mpt3sas driver. Another concern is that setting ioc->shost_recovery prevents new calls of scsih_qcmd() to submit any commands. But I don't think that setting that flag prevents any scsih_qcmd() calls that had already been started to submit a new command. In other words, I don't think that checking whether or not st->smid == 0 is sufficient to fix the reported race. Bart.
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(>tgt.sess_lock, flags);
> if (sess->deleted == QLA_SESS_DELETED)
> sess->logout_on_delete = 0;
>
> + spin_lock_irqsave(>vha->work_lock, flags);
> if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
> - spin_unlock_irqrestore(>tgt.sess_lock, flags);
> + spin_unlock_irqrestore(>vha->work_lock, flags);
> return;
> }
> sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
> - spin_unlock_irqrestore(>tgt.sess_lock, flags);
> + spin_unlock_irqrestore(>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(>tgt.sess_lock, flags);
> if (sess->deleted == QLA_SESS_DELETED)
> sess->logout_on_delete = 0;
>
> + spin_lock_irqsave(>vha->work_lock, flags);
> if (sess->deleted == QLA_SESS_DELETION_IN_PROGRESS) {
> - spin_unlock_irqrestore(>tgt.sess_lock, flags);
> + spin_unlock_irqrestore(>vha->work_lock, flags);
> return;
> }
> sess->deleted = QLA_SESS_DELETION_IN_PROGRESS;
> - spin_unlock_irqrestore(>tgt.sess_lock, flags);
> + spin_unlock_irqrestore(>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:
>>
Re: sd 6:0:0:0: [sdb] Unaligned partial completion
Will do. It'll be a few weeks, as I have to schedule downtime, but I'll
report back my results when it's done.
--Ted
On 06/11/2018 04:08 PM, James Bottomley wrote:
OK, try this: it will print a rate limited warning if it triggers
(showing it is this problem) and return ADD_TO_MLQUEUE for all the SAS
errors (we'll likely narrow this if it works, but for now let's do the
lot).
James
---
diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
index 8932ae81a15a..94aa5cb94064 100644
--- a/drivers/scsi/scsi_error.c
+++ b/drivers/scsi/scsi_error.c
@@ -531,6 +531,11 @@ int scsi_check_sense(struct scsi_cmnd *scmd)
if (sshdr.asc == 0xc1 && sshdr.ascq == 0x01 &&
sdev->sdev_bflags & BLIST_RETRY_ASC_C1)
return ADD_TO_MLQUEUE;
+ if (sshdr.asc == 0x4b) {
+ printk_ratelimited(KERN_WARNING "SAS/SATA link
retry\n");
+ return ADD_TO_MLQUEUE;
+ }
+
return NEEDS_RETRY;
case NOT_READY:
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
