From: Bart Van Assche <Bart.VanAssche@wdc.com>
To: "mauricfo@linux.vnet.ibm.com" <mauricfo@linux.vnet.ibm.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>
Cc: "chaitra.basappa@broadcom.com" <chaitra.basappa@broadcom.com>,
"sathya.prakash@broadcom.com" <sathya.prakash@broadcom.com>,
"suganath-prabu.subramani@broadcom.com"
<suganath-prabu.subramani@broadcom.com>,
"jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>
Subject: Re: [PATCH] scsi: mpt3sas: fix oops in error handlers after shutdown/unload
Date: Wed, 31 Jan 2018 19:06:01 +0000 [thread overview]
Message-ID: <1517425560.7325.2.camel@wdc.com> (raw)
In-Reply-To: <1517425200-19126-1-git-send-email-mauricfo@linux.vnet.ibm.com>
On Wed, 2018-01-31 at 17:00 -0200, Mauricio Faria de Oliveira wrote:
> This problem was observed with kexec on a system with a mpt3sas
> based adapter and an infiniband adapter which takes long enough
> to shutdown. The mpt3sas driver finished shuttting down, which
> disabled interruption handling, thus some running commands have
> not finished and timed out. Since the system was still running,
> waiting for the infiniband adapter to shut down, the scsi error
> handler for task abort of mpt3sas was invoked, and hit the oops
> because 'ioc->scsi_lookup' was NULL.
Sorry but I think this patch introduces new race conditions. Have you
considered to modify the mpt3sas driver such that interrupts are only
disabled after all commands have finished?
Thanks,
Bart.
next prev parent reply other threads:[~2018-01-31 19:06 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-31 19:00 [PATCH] scsi: mpt3sas: fix oops in error handlers after shutdown/unload Mauricio Faria de Oliveira
2018-01-31 19:06 ` Bart Van Assche [this message]
2018-01-31 19:48 ` Mauricio Faria de Oliveira
2018-01-31 22:59 ` Bart Van Assche
2018-02-01 19:54 ` Mauricio Faria de Oliveira
2018-01-31 19:24 ` [PATCH] test-case Mauricio Faria de Oliveira
2018-01-31 22:50 ` Bart Van Assche
2018-02-01 20:18 ` Mauricio Faria de Oliveira
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1517425560.7325.2.camel@wdc.com \
--to=bart.vanassche@wdc.com \
--cc=chaitra.basappa@broadcom.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=mauricfo@linux.vnet.ibm.com \
--cc=sathya.prakash@broadcom.com \
--cc=suganath-prabu.subramani@broadcom.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox