From: Bart Van Assche <Bart.VanAssche@sandisk.com>
To: "ming.lei@redhat.com" <ming.lei@redhat.com>
Cc: "linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"axboe@kernel.dk" <axboe@kernel.dk>
Subject: Re: [PATCH v3 0/5] Avoid that scsi-mq queue processing stalls
Date: Fri, 7 Apr 2017 15:18:19 +0000 [thread overview]
Message-ID: <1491578297.2559.7.camel@sandisk.com> (raw)
In-Reply-To: <20170407094107.GC27631@ming.t460p>
On Fri, 2017-04-07 at 17:41 +0800, Ming Lei wrote:
> On Thu, Apr 06, 2017 at 11:10:45AM -0700, Bart Van Assche wrote:
> > Hello Jens,
> >=20
> > The five patches in this patch series fix the queue lockup I reported
> > recently on the linux-block mailing list. Please consider these patches
> > for inclusion in the upstream kernel.
>=20
> I read the commit log of the 5 patches, looks not found descriptions
> about root cause of the queue lockup, so could you explain a bit about
> the reason behind?
Hello Ming,
If a .queue_rq() function returns BLK_MQ_RQ_QUEUE_BUSY then the block
driver that implements that function is responsible for rerunning the
hardware queue once requests can be queued successfully again. That is
not the case today for the SCSI core. Patch 5/5 ensures that hardware
queues for which scsi_queue_rq() has returned "busy" are rerun after
the "busy" condition has been cleared. This is why patch 5/5 fixes a
queue lockup.
Bart.=
next prev parent reply other threads:[~2017-04-07 15:18 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-06 18:10 [PATCH v3 0/5] Avoid that scsi-mq queue processing stalls Bart Van Assche
2017-04-06 18:10 ` [PATCH v3 1/5] blk-mq: Make it safe to use RCU to iterate over blk_mq_tag_set.tag_list Bart Van Assche
2017-04-07 9:46 ` Ming Lei
2017-04-07 15:15 ` Bart Van Assche
2017-04-06 18:10 ` [PATCH v3 2/5] blk-mq: Restart a single queue if tag sets are shared Bart Van Assche
2017-04-06 19:12 ` Jens Axboe
2017-04-06 19:21 ` Jens Axboe
2017-04-07 15:12 ` Bart Van Assche
2017-04-06 18:10 ` [PATCH v3 3/5] blk-mq: Clarify comments in blk_mq_dispatch_rq_list() Bart Van Assche
2017-04-06 18:10 ` [PATCH v3 4/5] blk-mq: Introduce blk_mq_delay_run_hw_queue() Bart Van Assche
2017-04-07 10:23 ` Ming Lei
2017-04-07 15:13 ` Bart Van Assche
2017-04-06 18:10 ` [PATCH v3 5/5] scsi: Avoid that SCSI queues get stuck Bart Van Assche
2017-04-07 9:41 ` [PATCH v3 0/5] Avoid that scsi-mq queue processing stalls Ming Lei
2017-04-07 15:18 ` Bart Van Assche [this message]
2017-04-07 15:34 ` Ming Lei
2017-04-07 15:46 ` Bart Van Assche
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=1491578297.2559.7.camel@sandisk.com \
--to=bart.vanassche@sandisk.com \
--cc=axboe@kernel.dk \
--cc=linux-block@vger.kernel.org \
--cc=ming.lei@redhat.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