There is a race between __bt_get_word() and bt_clear_tag(). Since
access to the tags bitmap is not serialized __bt_get_word() might
miss a tag which is about to or being returned by bt_clear_tag().
As result, the process requesting the tag might end up schedulled
out forever.
To avoid this corner case call io_schedule_timeout() instead of
io_schedule(). The timeout should be long enough to not falsely
wake up waiters often, so take the requests queue's "rq_timeout"
for that.
Signed-off-by: Alexander Gordeev <[email protected]>
Cc: Jens Axboe <[email protected]>
---
block/blk-mq-tag.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/block/blk-mq-tag.c b/block/blk-mq-tag.c
index c1b9242..1785f1f 100644
--- a/block/blk-mq-tag.c
+++ b/block/blk-mq-tag.c
@@ -256,7 +256,7 @@ static int bt_get(struct blk_mq_alloc_data *data,
blk_mq_put_ctx(data->ctx);
- io_schedule();
+ WARN_ON(!io_schedule_timeout(hctx->queue->rq_timeout));
data->ctx = blk_mq_get_ctx(data->q);
data->hctx = data->q->mq_ops->map_queue(data->q,
--
1.7.7.6
On 2014-07-21 10:10, Alexander Gordeev wrote:
> There is a race between __bt_get_word() and bt_clear_tag(). Since
> access to the tags bitmap is not serialized __bt_get_word() might
> miss a tag which is about to or being returned by bt_clear_tag().
> As result, the process requesting the tag might end up schedulled
> out forever.
>
> To avoid this corner case call io_schedule_timeout() instead of
> io_schedule(). The timeout should be long enough to not falsely
> wake up waiters often, so take the requests queue's "rq_timeout"
> for that.
What is this patch against?
--
Jens Axboe
On Mon, Jul 21, 2014 at 10:16:54AM +0200, Jens Axboe wrote:
> What is this patch against?
v3.16-rc5
> --
> Jens Axboe
>
--
Regards,
Alexander Gordeev
[email protected]
On 2014-07-21 10:32, Alexander Gordeev wrote:
> On Mon, Jul 21, 2014 at 10:16:54AM +0200, Jens Axboe wrote:
>> What is this patch against?
>
> v3.16-rc5
My bad, was looking at the wrong sources. What is the race? If the clear
and wakeup come in after the prepare_to_wait() but before the
io_schedule(), the io_schedule() will be a no-op and it wont actually
sleep. Your commit message doesn't mention any particular details.
--
Jens Axboe
On Mon, Jul 21, 2014 at 10:34:20AM +0200, Jens Axboe wrote:
> On 2014-07-21 10:32, Alexander Gordeev wrote:
> >On Mon, Jul 21, 2014 at 10:16:54AM +0200, Jens Axboe wrote:
> >>What is this patch against?
> >
> >v3.16-rc5
>
> My bad, was looking at the wrong sources. What is the race? If the
> clear and wakeup come in after the prepare_to_wait() but before the
> io_schedule(), the io_schedule() will be a no-op and it wont
> actually sleep. Your commit message doesn't mention any particular
> details.
Let me examine the code.. It was few weeks ago and I can not
remember what was that. And the changelog does not help :)
>
> --
> Jens Axboe
>
--
Regards,
Alexander Gordeev
[email protected]
On Mon, Jul 21, 2014 at 11:11:44AM +0200, Alexander Gordeev wrote:
> > My bad, was looking at the wrong sources. What is the race? If the
> > clear and wakeup come in after the prepare_to_wait() but before the
> > io_schedule(), the io_schedule() will be a no-op and it wont
> > actually sleep. Your commit message doesn't mention any particular
> > details.
>
> Let me examine the code.. It was few weeks ago and I can not
> remember what was that. And the changelog does not help :)
Jens,
I can not recall what was my concern. Sorry for the noise.
Thanks!
> > --
> > Jens Axboe
> >
--
Regards,
Alexander Gordeev
[email protected]