From: Keith Busch <keith.busch@linux.intel.com>
To: Bart Van Assche <Bart.VanAssche@wdc.com>
Cc: "linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"keith.busch@intel.com" <keith.busch@intel.com>,
"linux-block@vger.kernel.org" <linux-block@vger.kernel.org>,
"axboe@kernel.dk" <axboe@kernel.dk>,
"jianchao.w.wang@oracle.com" <jianchao.w.wang@oracle.com>,
"hch@lst.de" <hch@lst.de>,
"linux-nvme@lists.infradead.org" <linux-nvme@lists.infradead.org>
Subject: Re: [PATCHv2 2/2] scsi: set timed out out mq requests to complete
Date: Wed, 25 Jul 2018 10:48:31 -0600 [thread overview]
Message-ID: <20180725164831.GA16208@localhost.localdomain> (raw)
In-Reply-To: <bd7fe6618616db1c2de80386d1a916d86bccbcfd.camel@wdc.com>
On Wed, Jul 25, 2018 at 03:52:17PM +0000, Bart Van Assche wrote:
> On Mon, 2018-07-23 at 08:37 -0600, Keith Busch wrote:
> > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > index 8932ae81a15a..2715cdaa669c 100644
> > --- a/drivers/scsi/scsi_error.c
> > +++ b/drivers/scsi/scsi_error.c
> > @@ -296,6 +296,20 @@ enum blk_eh_timer_return scsi_times_out(struct request *req)
> > rtn = host->hostt->eh_timed_out(scmd);
> >
> > if (rtn == BLK_EH_DONE) {
> > + /*
> > + * For blk-mq, we must set the request state to complete now
> > + * before sending the request to the scsi error handler. This
> > + * will prevent a use-after-free in the event the LLD manages
> > + * to complete the request before the error handler finishes
> > + * processing this timed out request.
> > + *
> > + * If the request was already completed, then the LLD beat the
> > + * time out handler from transferring the request to the scsi
> > + * error handler. In that case we can return immediately as no
> > + * further action is required.
> > + */
> > + if (req->q->mq_ops && !blk_mq_mark_complete(req))
> > + return rtn;
> > if (scsi_abort_command(scmd) != SUCCESS) {
> > set_host_byte(scmd, DID_TIME_OUT);
> > scsi_eh_scmd_add(scmd);
>
> Hello Keith,
>
> What will happen if a completion occurs after scsi_times_out() has started and
> before or during the host->hostt->eh_timed_out()? Can that cause a use-after-free
> in .eh_timed_out()? Can that cause .eh_timed_out() to return BLK_EH_RESET_TIMER
> when it should return BLK_EH_DONE? Can that cause blk_mq_rq_timed_out() to call
> blk_add_timer() when that function shouldn't be called?
That's what the request's refcount protects. The whole point was that
driver returning RESET_TIMER doesn't lose the completion. In the worst
case scenario, the blk-mq timeout work spends some CPU cycles re-arming
a timer that it didn't need to.
WARNING: multiple messages have this Message-ID (diff)
From: keith.busch@linux.intel.com (Keith Busch)
Subject: [PATCHv2 2/2] scsi: set timed out out mq requests to complete
Date: Wed, 25 Jul 2018 10:48:31 -0600 [thread overview]
Message-ID: <20180725164831.GA16208@localhost.localdomain> (raw)
In-Reply-To: <bd7fe6618616db1c2de80386d1a916d86bccbcfd.camel@wdc.com>
On Wed, Jul 25, 2018@03:52:17PM +0000, Bart Van Assche wrote:
> On Mon, 2018-07-23@08:37 -0600, Keith Busch wrote:
> > diff --git a/drivers/scsi/scsi_error.c b/drivers/scsi/scsi_error.c
> > index 8932ae81a15a..2715cdaa669c 100644
> > --- a/drivers/scsi/scsi_error.c
> > +++ b/drivers/scsi/scsi_error.c
> > @@ -296,6 +296,20 @@ enum blk_eh_timer_return scsi_times_out(struct request *req)
> > rtn = host->hostt->eh_timed_out(scmd);
> >
> > if (rtn == BLK_EH_DONE) {
> > + /*
> > + * For blk-mq, we must set the request state to complete now
> > + * before sending the request to the scsi error handler. This
> > + * will prevent a use-after-free in the event the LLD manages
> > + * to complete the request before the error handler finishes
> > + * processing this timed out request.
> > + *
> > + * If the request was already completed, then the LLD beat the
> > + * time out handler from transferring the request to the scsi
> > + * error handler. In that case we can return immediately as no
> > + * further action is required.
> > + */
> > + if (req->q->mq_ops && !blk_mq_mark_complete(req))
> > + return rtn;
> > if (scsi_abort_command(scmd) != SUCCESS) {
> > set_host_byte(scmd, DID_TIME_OUT);
> > scsi_eh_scmd_add(scmd);
>
> Hello Keith,
>
> What will happen if a completion occurs after scsi_times_out() has started and
> before or during the host->hostt->eh_timed_out()? Can that cause a use-after-free
> in .eh_timed_out()? Can that cause .eh_timed_out() to return BLK_EH_RESET_TIMER
> when it should return BLK_EH_DONE? Can that cause blk_mq_rq_timed_out() to call
> blk_add_timer() when that function shouldn't be called?
That's what the request's refcount protects. The whole point was that
driver returning RESET_TIMER doesn't lose the completion. In the worst
case scenario, the blk-mq timeout work spends some CPU cycles re-arming
a timer that it didn't need to.
next prev parent reply other threads:[~2018-07-25 16:48 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-23 14:37 [PATCHv2 1/2] blk-mq: export setting request completion state Keith Busch
2018-07-23 14:37 ` Keith Busch
2018-07-23 14:37 ` [PATCHv2 2/2] scsi: set timed out out mq requests to complete Keith Busch
2018-07-23 14:37 ` Keith Busch
2018-07-24 7:56 ` Christoph Hellwig
2018-07-24 7:56 ` Christoph Hellwig
2018-07-24 22:46 ` Bart Van Assche
2018-07-24 22:46 ` Bart Van Assche
2018-07-25 1:15 ` Keith Busch
2018-07-25 1:15 ` Keith Busch
2018-07-25 1:56 ` Douglas Gilbert
2018-07-25 1:56 ` Douglas Gilbert
2018-07-25 2:48 ` Keith Busch
2018-07-25 2:48 ` Keith Busch
2018-07-25 15:52 ` Bart Van Assche
2018-07-25 15:52 ` Bart Van Assche
2018-07-25 16:48 ` Keith Busch [this message]
2018-07-25 16:48 ` Keith Busch
2018-07-24 7:56 ` [PATCHv2 1/2] blk-mq: export setting request completion state Christoph Hellwig
2018-07-24 7:56 ` Christoph Hellwig
2018-07-24 20:42 ` Jens Axboe
2018-07-24 20:42 ` Jens Axboe
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=20180725164831.GA16208@localhost.localdomain \
--to=keith.busch@linux.intel.com \
--cc=Bart.VanAssche@wdc.com \
--cc=axboe@kernel.dk \
--cc=hch@lst.de \
--cc=jianchao.w.wang@oracle.com \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=linux-scsi@vger.kernel.org \
/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.