Displaying 13 results from an estimated 13 matches for "blk_mq_tag_to_rq".
2014 Sep 11
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...ID: 44 Comm: kworker/u6:2 Not tainted 3.16.0-20140814.0.c66c84c.fc18-s390xfrob #1
[ 65.996043] Workqueue: writeback bdi_writeback_workfn (flush-251:32)
[ 65.996222] task: 0000000002250000 ti: 0000000002258000 task.ti: 0000000002258000
[ 65.996228] Krnl PSW : 0704f00180000000 00000000003ed114 (blk_mq_tag_to_rq+0x20/0x38)
[ 65.997299] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 EA:3
Krnl GPRS: 0000000000000040 cccccccccccccccc 0000000001619000 000000000000004e
[ 65.997301] 000000000000004e 0000000000000000 0000000000000001 0000000000a0de18
[ 65.997302]...
2014 Sep 11
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...ID: 44 Comm: kworker/u6:2 Not tainted 3.16.0-20140814.0.c66c84c.fc18-s390xfrob #1
[ 65.996043] Workqueue: writeback bdi_writeback_workfn (flush-251:32)
[ 65.996222] task: 0000000002250000 ti: 0000000002258000 task.ti: 0000000002258000
[ 65.996228] Krnl PSW : 0704f00180000000 00000000003ed114 (blk_mq_tag_to_rq+0x20/0x38)
[ 65.997299] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 EA:3
Krnl GPRS: 0000000000000040 cccccccccccccccc 0000000001619000 000000000000004e
[ 65.997301] 000000000000004e 0000000000000000 0000000000000001 0000000000a0de18
[ 65.997302]...
2014 Sep 12
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...ot tainted 3.16.0-20140814.0.c66c84c.fc18-s390xfrob #1
>> [ 65.996043] Workqueue: writeback bdi_writeback_workfn (flush-251:32)
>> [ 65.996222] task: 0000000002250000 ti: 0000000002258000 task.ti: 0000000002258000
>> [ 65.996228] Krnl PSW : 0704f00180000000 00000000003ed114 (blk_mq_tag_to_rq+0x20/0x38)
>> [ 65.997299] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 EA:3
>> Krnl GPRS: 0000000000000040 cccccccccccccccc 0000000001619000 000000000000004e
>> [ 65.997301] 000000000000004e 0000000000000000 0000000000000001 00000000...
2014 Sep 12
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...ot tainted 3.16.0-20140814.0.c66c84c.fc18-s390xfrob #1
>> [ 65.996043] Workqueue: writeback bdi_writeback_workfn (flush-251:32)
>> [ 65.996222] task: 0000000002250000 ti: 0000000002258000 task.ti: 0000000002258000
>> [ 65.996228] Krnl PSW : 0704f00180000000 00000000003ed114 (blk_mq_tag_to_rq+0x20/0x38)
>> [ 65.997299] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 EA:3
>> Krnl GPRS: 0000000000000040 cccccccccccccccc 0000000001619000 000000000000004e
>> [ 65.997301] 000000000000004e 0000000000000000 0000000000000001 00000000...
2014 Sep 12
0
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...orker/u6:2 Not tainted 3.16.0-20140814.0.c66c84c.fc18-s390xfrob #1
> [ 65.996043] Workqueue: writeback bdi_writeback_workfn (flush-251:32)
> [ 65.996222] task: 0000000002250000 ti: 0000000002258000 task.ti: 0000000002258000
> [ 65.996228] Krnl PSW : 0704f00180000000 00000000003ed114 (blk_mq_tag_to_rq+0x20/0x38)
> [ 65.997299] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 EA:3
> Krnl GPRS: 0000000000000040 cccccccccccccccc 0000000001619000 000000000000004e
> [ 65.997301] 000000000000004e 0000000000000000 0000000000000001 0000000000a0de18
>...
2014 Sep 17
0
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
....16.0-20140814.0.c66c84c.fc18-s390xfrob #1
>>> [ 65.996043] Workqueue: writeback bdi_writeback_workfn (flush-251:32)
>>> [ 65.996222] task: 0000000002250000 ti: 0000000002258000 task.ti: 0000000002258000
>>> [ 65.996228] Krnl PSW : 0704f00180000000 00000000003ed114 (blk_mq_tag_to_rq+0x20/0x38)
>>> [ 65.997299] R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 EA:3
>>> Krnl GPRS: 0000000000000040 cccccccccccccccc 0000000001619000 000000000000004e
>>> [ 65.997301] 000000000000004e 0000000000000000 0000000000000...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...eady 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 timeout still may see old cmd_flags and rq->q before
> rq's new initiali...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...eady 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 timeout still may see old cmd_flags and rq->q before
> rq's new initiali...
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...hen 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(). This uses bitmap_tags.
3. blk_mq_timeout_check() calls blk_mq_tag_to_rq() to get the rq.
Could we have a race between
- getting the tag (turning it busy) and initializing it and
- detecting a tag to be busy and trying to access it?
I haven't looked at the details yet. If so, we might either do some locking
(if there is existing infrastructure), or somehow mark...
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...hen 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(). This uses bitmap_tags.
3. blk_mq_timeout_check() calls blk_mq_tag_to_rq() to get the rq.
Could we have a race between
- getting the tag (turning it busy) and initializing it and
- detecting a tag to be busy and trying to access it?
I haven't looked at the details yet. If so, we might either do some locking
(if there is existing infrastructure), or somehow mark...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...g.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 4aac826..d24673f 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -514,6 +514,10 @@ struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags, unsigned int tag)
> {
> struct request *rq = tags->rqs[tag];
>
> + /* uninitialized request */
> + if (!rq->q || rq->tag == -1)
> + return rq;
> +
> if (!is_flush_request(rq, tag))
> return rq;
>
> @@ -1401,6 +1405,12...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...g.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 4aac826..d24673f 100644
> --- a/block/blk-mq.c
> +++ b/block/blk-mq.c
> @@ -514,6 +514,10 @@ struct request *blk_mq_tag_to_rq(struct blk_mq_tags *tags, unsigned int tag)
> {
> struct request *rq = tags->rqs[tag];
>
> + /* uninitialized request */
> + if (!rq->q || rq->tag == -1)
> + return rq;
> +
> if (!is_flush_request(rq, tag))
> return rq;
>
> @@ -1401,6 +1405,12...
2014 Sep 17
0
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...w_ctx/tag_sets are
fully initialized if you mean all requests have been used one time.
On Wed, Sep 17, 2014 at 10:11 PM, David Hildenbrand
> I was playing with a simple patch that just sets cmd_flags and action_flags to
What is action_flags?
> 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 timeout still may see old cmd_flags and rq->q before
rq's new initialization.
Thanks,
--
Ming Lei