From: Bart Van Assche <bvanassche@acm.org>
To: Jens Axboe <axboe@kernel.dk>
Cc: Christoph Hellwig <hch@lst.de>, Robert Elliott <elliott@hp.com>,
Ming Lei <ming.lei@canonical.com>,
Alexander Gordeev <agordeev@redhat.com>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: [PATCH 3/6] blk-mq: Fix a race between bt_clear_tag() and bt_get()
Date: Tue, 09 Dec 2014 16:58:35 +0100 [thread overview]
Message-ID: <54871C2B.8070605@acm.org> (raw)
In-Reply-To: <54871BD0.8020305@acm.org>
What we need is the following two guarantees:
* Any thread that observes the effect of the test_and_set_bit() by
__bt_get_word() also observes the preceding addition of 'current'
to the appropriate wait list. This is guaranteed by the semantics
of the spin_unlock() operation performed by prepare_and_wait().
Hence the conversion of test_and_set_bit_lock() into
test_and_set_bit().
* The wait lists are examined by bt_clear() after the tag bit has
been cleared. clear_bit_unlock() guarantees that any thread that
observes that the bit has been cleared also observes the store
operations preceding clear_bit_unlock(). However,
clear_bit_unlock() does not prevent that the wait lists are examined
before that the tag bit is cleared. Hence the addition of a memory
barrier between clear_bit() and the wait list examination.
Signed-off-by: Bart Van Assche <bvanassche@acm.org>
Cc: Christoph Hellwig <hch@lst.de>
Cc: Robert Elliott <elliott@hp.com>
Cc: Ming Lei <ming.lei@canonical.com>
Cc: Alexander Gordeev <agordeev@redhat.com>
Cc: <stable@vger.kernel.org> # v3.13+
---
block/blk-mq-tag.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index 5a3db28..70d9f9e 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -158,7 +158,7 @@ restart:
return -1;
}
last_tag = tag + 1;
- } while (test_and_set_bit_lock(tag, &bm->word));
+ } while (test_and_set_bit(tag, &bm->word));
return tag;
}
@@ -342,11 +342,10 @@ static void bt_clear_tag(struct blk_mq_bitmap_tags *bt, unsigned int tag)
struct bt_wait_state *bs;
int wait_cnt;
- /*
- * The unlock memory barrier need to order access to req in free
- * path and clearing tag bit
- */
- clear_bit_unlock(TAG_TO_BIT(bt, tag), &bt->map[index].word);
+ clear_bit(TAG_TO_BIT(bt, tag), &bt->map[index].word);
+
+ /* Ensure that the wait list checks occur after clear_bit(). */
+ smp_mb();
bs = bt_wake_ptr(bt);
if (!bs)
--
2.1.2
next prev parent reply other threads:[~2014-12-09 15:58 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 15:57 [PATCH 0/6] Six blk-mq patches Bart Van Assche
2014-12-09 15:57 ` [PATCH 1/6] blk-mq: Fix a use-after-free Bart Van Assche
2014-12-09 15:58 ` [PATCH 2/6] blk-mq: Avoid that __bt_get_word() wraps multiple times Bart Van Assche
2014-12-09 15:58 ` Bart Van Assche [this message]
2014-12-09 15:58 ` [PATCH 4/6] blk-mq: Avoid that I/O hangs in bt_get() Bart Van Assche
2014-12-09 16:10 ` Jens Axboe
2014-12-09 15:59 ` [PATCH 5/6] blk-mq: Use all available hardware queues Bart Van Assche
2014-12-09 16:10 ` Jens Axboe
2014-12-09 15:59 ` [PATCH 6/6] blk-mq: Micro-optimize bt_get() Bart Van Assche
2014-12-09 16:06 ` 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=54871C2B.8070605@acm.org \
--to=bvanassche@acm.org \
--cc=agordeev@redhat.com \
--cc=axboe@kernel.dk \
--cc=elliott@hp.com \
--cc=hch@lst.de \
--cc=linux-kernel@vger.kernel.org \
--cc=ming.lei@canonical.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).