From: Ming Lei <ming.lei@redhat.com>
To: Yufen Yu <yuyufen@huawei.com>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org, hch@infradead.org,
keith.busch@intel.com, tj@kernel.org, zhangxiaoxu5@huawei.com
Subject: Re: [PATCH] block: fix null pointer dereference in blk_mq_rq_timed_out()
Date: Tue, 17 Sep 2019 08:50:32 +0800 [thread overview]
Message-ID: <20190917005030.GD6199@ming.t460p> (raw)
In-Reply-To: <04b485ad-90e6-7752-b74f-9694de9c22a6@huawei.com>
On Mon, Sep 16, 2019 at 05:27:39PM +0800, Yufen Yu wrote:
>
>
> On 2019/9/12 18:07, Ming Lei wrote:
> > On Thu, Sep 12, 2019 at 04:49:15PM +0800, Yufen Yu wrote:
> > >
> > > On 2019/9/12 12:16, Ming Lei wrote:
> > > > On Thu, Sep 12, 2019 at 11:29:18AM +0800, Yufen Yu wrote:
> > > > > On 2019/9/12 10:46, Ming Lei wrote:
> > > > > > On Sat, Sep 07, 2019 at 06:24:50PM +0800, Yufen Yu wrote:
> > > > > > > There is a race condition between timeout check and completion for
> > > > > > > flush request as follow:
> > > > > > >
> > > > > > > timeout_work issue flush issue flush
> > > > > > > blk_insert_flush
> > > > > > > blk_insert_flush
> > > > > > > blk_mq_timeout_work
> > > > > > > blk_kick_flush
> > > > > > >
> > > > > > > blk_mq_queue_tag_busy_iter
> > > > > > > blk_mq_check_expired(flush_rq)
> > > > > > >
> > > > > > > __blk_mq_end_request
> > > > > > > flush_end_io
> > > > > > > blk_kick_flush
> > > > > > > blk_rq_init(flush_rq)
> > > > > > > memset(flush_rq, 0)
> > > > > > Not see there is memset(flush_rq, 0) in block/blk-flush.c
> > > > > Call path as follow:
> > > > >
> > > > > blk_kick_flush
> > > > > blk_rq_init
> > > > > memset(rq, 0, sizeof(*rq));
> > > > Looks I miss this one in blk_rq_init(), sorry for that.
> > > >
> > > > Given there are only two users of blk_rq_init(), one simple fix could be
> > > > not clearing queue in blk_rq_init(), something like below?
> > > >
> > > > diff --git a/block/blk-core.c b/block/blk-core.c
> > > > index 77807a5d7f9e..25e6a045c821 100644
> > > > --- a/block/blk-core.c
> > > > +++ b/block/blk-core.c
> > > > @@ -107,7 +107,9 @@ EXPORT_SYMBOL_GPL(blk_queue_flag_test_and_set);
> > > > void blk_rq_init(struct request_queue *q, struct request *rq)
> > > > {
> > > > - memset(rq, 0, sizeof(*rq));
> > > > + const int offset = offsetof(struct request, q);
> > > > +
> > > > + memset((void *)rq + offset, 0, sizeof(*rq) - offset);
> > > > INIT_LIST_HEAD(&rq->queuelist);
> > > > rq->q = q;
> > > > diff --git a/include/linux/blkdev.h b/include/linux/blkdev.h
> > > > index 1ac790178787..382e71b8787d 100644
> > > > --- a/include/linux/blkdev.h
> > > > +++ b/include/linux/blkdev.h
> > > > @@ -130,7 +130,7 @@ enum mq_rq_state {
> > > > * especially blk_mq_rq_ctx_init() to take care of the added fields.
> > > > */
> > > > struct request {
> > > > - struct request_queue *q;
> > > > + struct request_queue *q; /* Must be the 1st field */
> > > > struct blk_mq_ctx *mq_ctx;
> > > > struct blk_mq_hw_ctx *mq_hctx;
> > > Not set req->q as '0' can just avoid BUG_ON for NULL pointer deference.
> > >
> > > However, the root problem is that 'flush_rq' have been reused while
> > > timeout function handle it currently. That means mq_ops->timeout() may
> > > access old values remained by the last flush request and make the wrong
> > > decision.
> > >
> > > Take the race condition in the patch as an example.
> > >
> > > blk_mq_check_expired
> > > blk_mq_rq_timed_out
> > > req->q->mq_ops->timeout // Driver timeout handle may read old data
> > > refcount_dec_and_test(&rq)
> > > __blk_mq_free_request // If rq have been reset has '1' in
> > > blk_rq_init(), it will be free here.
> > >
> > > So, I think we should solve this problem completely. Just like normal
> > > request,
> > > we can prevent flush request to call end_io when timeout handle the request.
> > Seems it isn't specific for 'flush_rq', and it should be one generic issue
> > for any request which implements .end_io.
> >
> > For requests without defining .end_io, rq->ref is applied for protecting
> > its lifetime. However, rq->end_io() is still called even if rq->ref doesn't
> > drop to zero.
> >
> > If the above is correct, we need to let rq->ref to cover rq->end_io().
>
> We ignore the fact that we may also need to free 'rq' after calling
> rq->end_io(),
> such as end_clone_request(), mq_flush_data_end_io().
>
> If we let 'rq->ref' to cover rq->end_io(), 'rq->ref' have been decreased to
> '0'
> before calling __blk_mq_free_request(). Then, the function will never be
> called.
>
> So, I think flush request may need to be fixed individually.
Thinking of this issue further, given other cases of .end_io() still
depends on blk_mq_free_request() for freeing request, it is fine
to just fix flush request.
Thanks,
Ming
next prev parent reply other threads:[~2019-09-17 0:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-07 10:24 [PATCH] block: fix null pointer dereference in blk_mq_rq_timed_out() Yufen Yu
2019-09-12 2:46 ` Ming Lei
2019-09-12 3:29 ` Yufen Yu
2019-09-12 4:16 ` Ming Lei
2019-09-12 8:49 ` Yufen Yu
2019-09-12 10:07 ` Ming Lei
2019-09-16 2:40 ` Yufen Yu
2019-09-16 9:27 ` Yufen Yu
2019-09-17 0:50 ` Ming Lei [this message]
2019-09-12 8:59 ` Guoqing Jiang
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=20190917005030.GD6199@ming.t460p \
--to=ming.lei@redhat.com \
--cc=axboe@kernel.dk \
--cc=hch@infradead.org \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=tj@kernel.org \
--cc=yuyufen@huawei.com \
--cc=zhangxiaoxu5@huawei.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).