From: "jianchao.wang" <jianchao.w.wang@oracle.com>
To: Bart Van Assche <bvanassche@acm.org>, Christoph Hellwig <hch@lst.de>
Cc: axboe@kernel.dk, linux-block@vger.kernel.org,
jsmart2021@gmail.com, josef@toxicpanda.com,
linux-nvme@lists.infradead.org, linux-kernel@vger.kernel.org,
keith.busch@intel.com, hare@suse.de, jthumshirn@suse.de,
sagi@grimberg.me
Subject: Re: [PATCH 0/8]: blk-mq: use static_rqs to iterate busy tags
Date: Mon, 18 Mar 2019 10:47:57 +0800 [thread overview]
Message-ID: <8cff92a3-2f25-18a7-265f-9bff7d8cc3fc@oracle.com> (raw)
In-Reply-To: <1552666744.45180.135.camel@acm.org>
Hi Bart
On 3/16/19 12:19 AM, Bart Van Assche wrote:
>> This stale request maybe something that has been freed due to io scheduler
>> is detached or a q using a shared tagset is gone.
>>
>> And also the blk_mq_timeout_work could use it to pick up the expired request.
>> The driver would also use it to requeue the in-flight requests when the device is dead.
>>
>> Compared with adding more synchronization, using static_rqs[] directly maybe simpler :)
> Hi Jianchao,
>
> Although I appreciate your work: I agree with Christoph that we should avoid races
> like this rather than modifying the block layer to make sure that such races are
> handled safely.
The root cause here is that there is window between set tag sbitmap and set tags->rqs[]
, and we don't clear the tags->rqs[] in free tags path. So when we iterate the busy
tags, we could see stale requests in tags->rqs[] and this stale requests maybe freed.
Looks like it is difficult to close the window above, so we used to try to clear the
tags->rqs[] in two ways,
1. clear the tags->rqs[] in the request free path
Jens doesn't like it
https://marc.info/?l=linux-block&m=154515671524877&w=2
"
It's an extra store, and it's a store to an area that's then now shared
between issue and completion. Those are never a good idea. Besides, it's
the kind of issue you solve in the SLOW path, not in the fast path. Since
that's doable, it would be silly to do it for every IO.
"
2. clear the associated slots in tags->tags[] when blk_mq_free_rqs
https://marc.info/?l=linux-block&m=154534605914798&w=2
+ rcu_read_lock();
sbitmap_for_each_set(&bt->sb, bt_iter, &iter_data);
+ rcu_read_unlock();
The busy_iter_fn could sleep
blk_mq_check_expired
-> blk_mq_rq_timed_out
-> q->mq_ops->timeout
nvme_timeout
-> nvme_dev_disable
-> mutex_lock dev->shutdown_lock
Since it is not so flexible to fix on tags->rqs[], why not try to use tags->static_rqs[] ?
Then we wound never care about the stable requests any more.
Thanks
Jianchao
next prev parent reply other threads:[~2019-03-18 2:45 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 8:57 Jianchao Wang
2019-03-15 8:57 ` [PATCH 1/8] blk-mq: get rid of the synchronize_rcu in __blk_mq_update_nr_hw_queues Jianchao Wang
2019-03-17 6:14 ` Ming Lei
2019-03-15 8:57 ` [PATCH 2/8] blk-mq: change the method of iterating busy tags of a request_queue Jianchao Wang
2019-03-15 16:16 ` Keith Busch
2019-03-17 6:50 ` Ming Lei
2019-03-18 15:53 ` Keith Busch
2019-03-18 1:49 ` jianchao.wang
2019-03-20 18:52 ` Sagi Grimberg
2019-03-21 1:33 ` jianchao.wang
2019-03-15 8:57 ` [PATCH 3/8] blk-mq: use blk_mq_queue_tag_busy_iter in debugfs Jianchao Wang
2019-03-15 8:57 ` [PATCH 4/8] mtip32xx: use blk_mq_queue_tag_busy_iter Jianchao Wang
2019-03-15 8:57 ` [PATCH 5/8] nbd: " Jianchao Wang
2019-03-18 17:16 ` Bart Van Assche
2019-03-19 2:04 ` jianchao.wang
2019-03-15 8:57 ` [PATCH 6/8] skd: " Jianchao Wang
2019-03-18 17:20 ` Bart Van Assche
2019-03-19 1:54 ` jianchao.wang
2019-03-15 8:57 ` [PATCH 7/8] nvme: " Jianchao Wang
2019-03-15 16:33 ` James Smart
2019-03-15 16:39 ` James Smart
2019-03-15 16:49 ` Hannes Reinecke
2019-03-18 7:00 ` jianchao.wang
2019-03-15 8:57 ` [PATCH 8/8] blk-mq: remove blk_mq_tagset_busy_iter Jianchao Wang
2019-03-15 9:20 ` [PATCH 0/8]: blk-mq: use static_rqs to iterate busy tags Christoph Hellwig
2019-03-15 9:44 ` jianchao.wang
2019-03-15 16:19 ` Bart Van Assche
2019-03-18 2:47 ` jianchao.wang [this message]
2019-03-15 13:30 ` Josef Bacik
2019-03-18 17:28 ` Bart Van Assche
2019-03-19 1:25 ` jianchao.wang
2019-03-19 15:10 ` Bart Van Assche
2019-03-19 15:25 ` Keith Busch
2019-03-20 18:38 ` Sagi Grimberg
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=8cff92a3-2f25-18a7-265f-9bff7d8cc3fc@oracle.com \
--to=jianchao.w.wang@oracle.com \
--cc=axboe@kernel.dk \
--cc=bvanassche@acm.org \
--cc=hare@suse.de \
--cc=hch@lst.de \
--cc=josef@toxicpanda.com \
--cc=jsmart2021@gmail.com \
--cc=jthumshirn@suse.de \
--cc=keith.busch@intel.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-nvme@lists.infradead.org \
--cc=sagi@grimberg.me \
/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
all inboxes | Powered by JetHome®