Displaying 8 results from an estimated 8 matches for "blk_mq_rq_ctx_init".
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...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_tag_busy_iter() is used to call blk_mq_timeout_check() on all busy
tags.
2. This is done by collecting all free tags using bt_for_each_free() and
handing them to blk_mq_timeout_check()...
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...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_tag_busy_iter() is used to call blk_mq_timeout_check() on all busy
tags.
2. This is done by collecting all free tags using bt_for_each_free() and
handing them to blk_mq_timeout_check()...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...t is action_flags?
atomic_flags, sorry :)
Otherwise e.g. REQ_ATOM_STARTED could already be set due to the randomness. I
am not sure if this is really necessary, or if it is completely shielded by the
tag-handling code, but seemed to be clean for me to do it (and I remember it
not being set within blk_mq_rq_ctx_init).
>
> > 0. That should already be sufficient to hinder blk_mq_tag_to_rq and the calling
> > method to do the wrong thing.
>
> Yes, clearing rq->cmd_flags should be enough.
>
> And looks better to move rq initialization to __blk_mq_free_request()
> too, otherwise...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...t is action_flags?
atomic_flags, sorry :)
Otherwise e.g. REQ_ATOM_STARTED could already be set due to the randomness. I
am not sure if this is really necessary, or if it is completely shielded by the
tag-handling code, but seemed to be clean for me to do it (and I remember it
not being set within blk_mq_rq_ctx_init).
>
> > 0. That should already be sufficient to hinder blk_mq_tag_to_rq and the calling
> > method to do the wrong thing.
>
> Yes, clearing rq->cmd_flags should be enough.
>
> And looks better to move rq initialization to __blk_mq_free_request()
> too, otherwise...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...ming.lei at canonical.com>
> Date: Wed, 17 Sep 2014 21:00:34 +0800
> Subject: [PATCH] blk-mq: initialize request before the 1st allocation
>
> Otherwise the request can be accessed from timeout handler
> just after its 1st allocation from tag pool and before
> initialization in blk_mq_rq_ctx_init(), so cause oops since
> the request is filled up with garbage data.
>
> Signed-off-by: Ming Lei <ming.lei at canonical.com>
> ---
> block/blk-mq.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 4aac...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...ming.lei at canonical.com>
> Date: Wed, 17 Sep 2014 21:00:34 +0800
> Subject: [PATCH] blk-mq: initialize request before the 1st allocation
>
> Otherwise the request can be accessed from timeout handler
> just after its 1st allocation from tag pool and before
> initialization in blk_mq_rq_ctx_init(), so cause oops since
> the request is filled up with garbage data.
>
> Signed-off-by: Ming Lei <ming.lei at canonical.com>
> ---
> block/blk-mq.c | 10 ++++++++++
> 1 file changed, 10 insertions(+)
>
> diff --git a/block/blk-mq.c b/block/blk-mq.c
> index 4aac...
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