Displaying 14 results from an estimated 14 matches for "blk_mq_init_rq_map".
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...t; > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
Digging through the code, I think I found a possible cause:
tags->rqs[..] is not initialized with zeroes (via alloc_pages_node in
blk-mq.c:blk_mq_init_rq_map()).
When a request is created:
1. __blk_mq_alloc_request() gets a free tag (thus e.g. removing it from
bitmap_tags)
2. __blk_mq_alloc_request() initializes is via blk_mq_rq_ctx_init(). The struct
is filled with life and rq->q is set.
When blk_mq_hw_ctx_check_timeout() is called:
1. blk_mq_...
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...t; > the body of a message to majordomo at vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
Digging through the code, I think I found a possible cause:
tags->rqs[..] is not initialized with zeroes (via alloc_pages_node in
blk-mq.c:blk_mq_init_rq_map()).
When a request is created:
1. __blk_mq_alloc_request() gets a free tag (thus e.g. removing it from
bitmap_tags)
2. __blk_mq_alloc_request() initializes is via blk_mq_rq_ctx_init(). The struct
is filled with life and rq->q is set.
When blk_mq_hw_ctx_check_timeout() is called:
1. blk_mq_...
2014 Sep 18
3
[PATCH] blk-mq: Avoid race condition with uninitialized requests
This patch should fix the bug reported in https://lkml.org/lkml/2014/9/11/249.
Test is still pending.
David Hildenbrand (1):
blk-mq: Avoid race condition with uninitialized requests
block/blk-mq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
1.8.5.5
2014 Sep 18
3
[PATCH] blk-mq: Avoid race condition with uninitialized requests
This patch should fix the bug reported in https://lkml.org/lkml/2014/9/11/249.
Test is still pending.
David Hildenbrand (1):
blk-mq: Avoid race condition with uninitialized requests
block/blk-mq.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
--
1.8.5.5
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...gt;>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>> Digging through the code, I think I found a possible cause:
>>
>> tags->rqs[..] is not initialized with zeroes (via alloc_pages_node in
>> blk-mq.c:blk_mq_init_rq_map()).
>
> Yes, it may cause problem when the request is allocated at the 1st time,
> and timeout handler may comes just after the allocation and before its
> initialization, then oops triggered because of garbage data in the request.
>
> --
> From ffd0824b7b686074c2d5d70bc4e6bba...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...gt;>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>
>>
>> Digging through the code, I think I found a possible cause:
>>
>> tags->rqs[..] is not initialized with zeroes (via alloc_pages_node in
>> blk-mq.c:blk_mq_init_rq_map()).
>
> Yes, it may cause problem when the request is allocated at the 1st time,
> and timeout handler may comes just after the allocation and before its
> initialization, then oops triggered because of garbage data in the request.
>
> --
> From ffd0824b7b686074c2d5d70bc4e6bba...
2014 Sep 17
0
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...mo at vger.kernel.org
> > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > >
> >
>
> Digging through the code, I think I found a possible cause:
>
> tags->rqs[..] is not initialized with zeroes (via alloc_pages_node in
> blk-mq.c:blk_mq_init_rq_map()).
Yes, it may cause problem when the request is allocated at the 1st time,
and timeout handler may comes just after the allocation and before its
initialization, then oops triggered because of garbage data in the request.
--
2014 Sep 18
0
[PATCH] blk-mq: Avoid race condition with uninitialized requests
...struct blk_mq_hw_ctx *hctx,
if (rq->cmd_flags & REQ_MQ_INFLIGHT)
atomic_dec(&hctx->nr_active);
+ rq->cmd_flags = 0;
clear_bit(REQ_ATOM_STARTED, &rq->atomic_flags);
blk_mq_put_tag(hctx, tag, &ctx->last_tag);
@@ -1404,6 +1404,8 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct blk_mq_tag_set *set,
left -= to_do * rq_size;
for (j = 0; j < to_do; j++) {
tags->rqs[i] = p;
+ tags->rqs[i]->atomic_flags = 0;
+ tags->rqs[i]->cmd_flags = 0;
if (set->ops->init_request) {
if (set->ops->init_request(set->driver_data,...
2014 Sep 22
1
[PATCH] blk-mq: Avoid race condition with uninitialized requests
...if (rq->cmd_flags & REQ_MQ_INFLIGHT)
> atomic_dec(&hctx->nr_active);
> + rq->cmd_flags = 0;
>
> clear_bit(REQ_ATOM_STARTED, &rq->atomic_flags);
> blk_mq_put_tag(hctx, tag, &ctx->last_tag);
> @@ -1404,6 +1404,8 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct blk_mq_tag_set *set,
> left -= to_do * rq_size;
> for (j = 0; j < to_do; j++) {
> tags->rqs[i] = p;
> + tags->rqs[i]->atomic_flags = 0;
> + tags->rqs[i]->cmd_flags = 0;
> if (set->ops->init_request) {
> if (set->ops->i...
2014 Sep 22
1
[PATCH] blk-mq: Avoid race condition with uninitialized requests
...if (rq->cmd_flags & REQ_MQ_INFLIGHT)
> atomic_dec(&hctx->nr_active);
> + rq->cmd_flags = 0;
>
> clear_bit(REQ_ATOM_STARTED, &rq->atomic_flags);
> blk_mq_put_tag(hctx, tag, &ctx->last_tag);
> @@ -1404,6 +1404,8 @@ static struct blk_mq_tags *blk_mq_init_rq_map(struct blk_mq_tag_set *set,
> left -= to_do * rq_size;
> for (j = 0; j < to_do; j++) {
> tags->rqs[i] = p;
> + tags->rqs[i]->atomic_flags = 0;
> + tags->rqs[i]->cmd_flags = 0;
> if (set->ops->init_request) {
> if (set->ops->i...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
> On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe <axboe at kernel.dk> wrote:
> >
> > Another way would be to ensure that the timeout handler doesn't touch hw_ctx
> > or tag_sets that aren't fully initialized yet. But I think this is
> > safer/cleaner.
>
> That may not be easy or enough to check if hw_ctx/tag_sets are
> fully initialized if you mean
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
> On Wed, Sep 17, 2014 at 10:22 PM, Jens Axboe <axboe at kernel.dk> wrote:
> >
> > Another way would be to ensure that the timeout handler doesn't touch hw_ctx
> > or tag_sets that aren't fully initialized yet. But I think this is
> > safer/cleaner.
>
> That may not be easy or enough to check if hw_ctx/tag_sets are
> fully initialized if you mean
2014 Sep 12
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
On 09/12/2014 01:54 PM, Ming Lei wrote:
> On Thu, Sep 11, 2014 at 6:26 PM, Christian Borntraeger
> <borntraeger at de.ibm.com> wrote:
>> Folks,
>>
>> we have seen the following bug with 3.16 as a KVM guest. It suspect the blk-mq rework that happened between 3.15 and 3.16, but it can be something completely different.
>>
>
> Care to share how you reproduce
2014 Sep 12
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
On 09/12/2014 01:54 PM, Ming Lei wrote:
> On Thu, Sep 11, 2014 at 6:26 PM, Christian Borntraeger
> <borntraeger at de.ibm.com> wrote:
>> Folks,
>>
>> we have seen the following bug with 3.16 as a KVM guest. It suspect the blk-mq rework that happened between 3.15 and 3.16, but it can be something completely different.
>>
>
> Care to share how you reproduce