search for: blk_mq_map_request

Displaying 11 results from an estimated 11 matches for "blk_mq_map_request".

2014 Sep 11
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...;000000000010bc08>] do_IRQ+0x64/0x84 [ 66.437533] [<000000000067ccd8>] ext_skip+0x42/0x46 [ 66.437541] [<00000000003ed7b4>] __blk_mq_alloc_request+0x58/0x1e8 [ 66.437544] ([<00000000003ed788>] __blk_mq_alloc_request+0x2c/0x1e8) [ 66.437547] [<00000000003eef82>] blk_mq_map_request+0xc2/0x208 [ 66.437549] [<00000000003ef860>] blk_sq_make_request+0xac/0x350 [ 66.437721] [<00000000003e2d6c>] generic_make_request+0xc4/0xfc [ 66.437723] [<00000000003e2e56>] submit_bio+0xb2/0x1a8 [ 66.438373] [<000000000031e8aa>] ext4_io_submit+0x52/0x80 [ 66....
2014 Sep 11
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...;000000000010bc08>] do_IRQ+0x64/0x84 [ 66.437533] [<000000000067ccd8>] ext_skip+0x42/0x46 [ 66.437541] [<00000000003ed7b4>] __blk_mq_alloc_request+0x58/0x1e8 [ 66.437544] ([<00000000003ed788>] __blk_mq_alloc_request+0x2c/0x1e8) [ 66.437547] [<00000000003eef82>] blk_mq_map_request+0xc2/0x208 [ 66.437549] [<00000000003ef860>] blk_sq_make_request+0xac/0x350 [ 66.437721] [<00000000003e2d6c>] generic_make_request+0xc4/0xfc [ 66.437723] [<00000000003e2e56>] submit_bio+0xb2/0x1a8 [ 66.438373] [<000000000031e8aa>] ext4_io_submit+0x52/0x80 [ 66....
2014 Sep 12
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...x84 >> [ 66.437533] [<000000000067ccd8>] ext_skip+0x42/0x46 >> [ 66.437541] [<00000000003ed7b4>] __blk_mq_alloc_request+0x58/0x1e8 >> [ 66.437544] ([<00000000003ed788>] __blk_mq_alloc_request+0x2c/0x1e8) >> [ 66.437547] [<00000000003eef82>] blk_mq_map_request+0xc2/0x208 >> [ 66.437549] [<00000000003ef860>] blk_sq_make_request+0xac/0x350 >> [ 66.437721] [<00000000003e2d6c>] generic_make_request+0xc4/0xfc >> [ 66.437723] [<00000000003e2e56>] submit_bio+0xb2/0x1a8 >> [ 66.438373] [<000000000031e8aa&g...
2014 Sep 12
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...x84 >> [ 66.437533] [<000000000067ccd8>] ext_skip+0x42/0x46 >> [ 66.437541] [<00000000003ed7b4>] __blk_mq_alloc_request+0x58/0x1e8 >> [ 66.437544] ([<00000000003ed788>] __blk_mq_alloc_request+0x2c/0x1e8) >> [ 66.437547] [<00000000003eef82>] blk_mq_map_request+0xc2/0x208 >> [ 66.437549] [<00000000003ef860>] blk_sq_make_request+0xac/0x350 >> [ 66.437721] [<00000000003e2d6c>] generic_make_request+0xc4/0xfc >> [ 66.437723] [<00000000003e2e56>] submit_bio+0xb2/0x1a8 >> [ 66.438373] [<000000000031e8aa&g...
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...t;> > >> That is very weird, the 'rq' is got from hctx->tags, and rq should be > >> valid, and rq->q shouldn't have been changed even though it was > >> double free or double allocation. > >> > >>> I am currently asking myself if blk_mq_map_request should protect against softirq here but I cant say for sure,as I have never looked into that code before. > >> > >> No, it needn't the protection. > >> > >> Thanks, > >> > > > > -- > > To unsubscribe from this list: send the line &...
2014 Sep 17
3
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...t;> > >> That is very weird, the 'rq' is got from hctx->tags, and rq should be > >> valid, and rq->q shouldn't have been changed even though it was > >> double free or double allocation. > >> > >>> I am currently asking myself if blk_mq_map_request should protect against softirq here but I cant say for sure,as I have never looked into that code before. > >> > >> No, it needn't the protection. > >> > >> Thanks, > >> > > > > -- > > To unsubscribe from this list: send the line &...
2014 Sep 12
0
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...;] do_IRQ+0x64/0x84 > [ 66.437533] [<000000000067ccd8>] ext_skip+0x42/0x46 > [ 66.437541] [<00000000003ed7b4>] __blk_mq_alloc_request+0x58/0x1e8 > [ 66.437544] ([<00000000003ed788>] __blk_mq_alloc_request+0x2c/0x1e8) > [ 66.437547] [<00000000003eef82>] blk_mq_map_request+0xc2/0x208 > [ 66.437549] [<00000000003ef860>] blk_sq_make_request+0xac/0x350 > [ 66.437721] [<00000000003e2d6c>] generic_make_request+0xc4/0xfc > [ 66.437723] [<00000000003e2e56>] submit_bio+0xb2/0x1a8 > [ 66.438373] [<000000000031e8aa>] ext4_io_subm...
2014 Sep 17
0
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...[ 66.437533] [<000000000067ccd8>] ext_skip+0x42/0x46 >>> [ 66.437541] [<00000000003ed7b4>] __blk_mq_alloc_request+0x58/0x1e8 >>> [ 66.437544] ([<00000000003ed788>] __blk_mq_alloc_request+0x2c/0x1e8) >>> [ 66.437547] [<00000000003eef82>] blk_mq_map_request+0xc2/0x208 >>> [ 66.437549] [<00000000003ef860>] blk_sq_make_request+0xac/0x350 >>> [ 66.437721] [<00000000003e2d6c>] generic_make_request+0xc4/0xfc >>> [ 66.437723] [<00000000003e2e56>] submit_bio+0xb2/0x1a8 >>> [ 66.438373] [<00...
2014 Sep 17
0
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...That is very weird, the 'rq' is got from hctx->tags, and rq should be > > >> valid, and rq->q shouldn't have been changed even though it was > > >> double free or double allocation. > > >> > > >>> I am currently asking myself if blk_mq_map_request should protect against softirq here but I cant say for sure,as I have never looked into that code before. > > >> > > >> No, it needn't the protection. > > >> > > >> Thanks, > > >> > > > > > > -- > > > To uns...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...very weird, the 'rq' is got from hctx->tags, and rq should be >>>>> valid, and rq->q shouldn't have been changed even though it was >>>>> double free or double allocation. >>>>> >>>>>> I am currently asking myself if blk_mq_map_request should protect against softirq here but I cant say for sure,as I have never looked into that code before. >>>>> >>>>> No, it needn't the protection. >>>>> >>>>> Thanks, >>>>> >>>> >>>> -- >>...
2014 Sep 17
2
blk-mq crash under KVM in multiqueue block code (with virtio-blk and ext4)
...very weird, the 'rq' is got from hctx->tags, and rq should be >>>>> valid, and rq->q shouldn't have been changed even though it was >>>>> double free or double allocation. >>>>> >>>>>> I am currently asking myself if blk_mq_map_request should protect against softirq here but I cant say for sure,as I have never looked into that code before. >>>>> >>>>> No, it needn't the protection. >>>>> >>>>> Thanks, >>>>> >>>> >>>> -- >>...