From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"hch@infradead.org" <hch@infradead.org>,
"jbaron@akamai.com" <jbaron@akamai.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"sagi@grimberg.me" <sagi@grimberg.me>,
"sathya.prakash@broadcom.com" <sathya.prakash@broadcom.com>,
"suganath-prabu.subramani@broadcom.com"
<suganath-prabu.subramani@broadcom.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"hare@suse.de" <hare@suse.de>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"hch@lst.de" <hch@lst.de>,
"davem@davemloft.net" <davem@davemloft.net>,
"Sreekanth.Reddy@broadcom.com" <Sreekanth.Reddy@broadcom.com>,
"chaitra.basappa@broadcom.com" <chaitra.basappa@broadcom.com>,
"dledford@redhat.com" <dledford@redhat.com>
Subject: Re: [PATCH] scsi: mpt3sas: fix hang on ata passthru commands
Date: Sun, 1 Jan 2017 14:22:11 +0000 [thread overview]
Message-ID: <1483280506.5512.1.camel@sandisk.com> (raw)
In-Reply-To: <1483226343.2518.32.camel@linux.vnet.ibm.com>
On Sat, 2016-12-31 at 15:19 -0800, James Bottomley wrote:
> On Thu, 2016-12-29 at 00:02 -0800, Christoph Hellwig wrote:
> > On Wed, Dec 28, 2016 at 11:30:24PM -0500, Jason Baron wrote:
> > > Add a new parameter to scsi_internal_device_block() to decide
> > > whether or not to invoke scsi_wait_for_queuecommand().
> >
> > We'll also need to deal with the blk-mq wait path that Bart has been
> > working on (I think it's already in the scsi tree, but I'd have to
> > check).
> >
> > Also adding a bool flag for the last call in a function is style
> > that's a little annoying.
> >
> > I'd prefer to add a scsi_internal_device_block_nowait that contains
> > all the code except for the waiting, and then make
> > scsi_internal_device_block_nowait a wrapper around it. Or drop the
> > annoying internal for both while we're at it :)
>
> OK, I know it's new year, but this is an unpatched regression in -rc1
> that's causing serious issues. I would like this fixed by -rc3 so we
> have 3 options
>
> 1. revert all the queuecommand wait stuff until it proves it's actually
> working without regressions
> 2. apply this patch and fix the style issues later
> 3. someone else supplies the correctly styled fix patch
>
> The conservative in me says that 1. is probably the most correct thing
> to do because it gives us time to get the queuecommand wait stuff
> right; that's what I'll probably do if there's no movement next week.
> However, since we're reasonably early in the -rc cycle, so either 2 or
> 3 are viable provided no further regressions caused by the queuecommand
> wait stuff pop up.
Hello James,
My recommendation is to revert commit 18f6084a989b ("scsi: mpt3sas: Fix
secure erase premature termination"). Since the mpt3sas driver uses the
single-queue approach and since the SCSI core unlocks the block layer
request queue lock before the .queuecommand callback function is called,
multiple threads can execute that callback function (scsih_qcmd() in this
case) simultaneously. This means that using scsi_internal_device_block()
from inside .queuecommand to serialize SCSI command execution is wrong.
Bart.
next prev parent reply other threads:[~2017-01-01 14:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-29 4:30 [PATCH] scsi: mpt3sas: fix hang on ata passthru commands Jason Baron
2016-12-29 8:02 ` Christoph Hellwig
2016-12-29 16:02 ` Jason Baron
2016-12-31 23:19 ` James Bottomley
2017-01-01 14:22 ` Bart Van Assche [this message]
2017-01-01 15:30 ` Jason Baron
2017-01-01 16:33 ` David Miller
2017-01-01 17:39 ` James Bottomley
2017-01-03 20:46 ` Jason Baron
2017-01-15 17:01 ` James Bottomley
2017-01-16 16:20 ` Bart Van Assche
2017-01-06 1:59 ` Martin K. Petersen
2017-01-06 15:46 ` Sreekanth Reddy
2017-01-10 4:50 ` Martin K. Petersen
2017-01-16 20:01 ` James Bottomley
2017-01-16 21:01 ` Martin K. Petersen
2017-01-17 9:20 ` Ingo Molnar
2017-01-17 14:13 ` Sreekanth Reddy
2017-01-17 14:15 ` Christoph Hellwig
2017-01-17 19:44 ` Martin K. Petersen
2017-01-17 14:44 ` James Bottomley
2016-12-29 16:16 ` David Miller
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=1483280506.5512.1.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=Sreekanth.Reddy@broadcom.com \
--cc=chaitra.basappa@broadcom.com \
--cc=davem@davemloft.net \
--cc=dledford@redhat.com \
--cc=hare@suse.de \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=jbaron@akamai.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=sagi@grimberg.me \
--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;
as well as URLs for NNTP newsgroup(s).