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:22 UTC|newest]
Thread overview: 26+ 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-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-10 4:50 ` Martin K. Petersen
2017-01-16 20:01 ` James Bottomley
2017-01-16 21:01 ` Martin K. Petersen
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 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.