All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] block: reset mapping if failed to update hardware queue count
@ 2020-05-13  0:44 Weiping Zhang
  2020-05-13  2:20 ` Jens Axboe
  0 siblings, 1 reply; 3+ messages in thread
From: Weiping Zhang @ 2020-05-13  0:44 UTC (permalink / raw)
  To: axboe, bvanassche, tom.leiming; +Cc: linux-block

When we increase hardware queue count, blk_mq_update_queue_map will
reset the mapping between cpu and hardware queue base on the hardware
queue count(set->nr_hw_queues). The mapping cannot be reset if it
encounters error in blk_mq_realloc_hw_ctxs, but the fallback flow will
continue using it, then blk_mq_map_swqueue will touch a invalid memory,
because the mapping points to a wrong hctx.

blktest block/030:

null_blk: module loaded
Increasing nr_hw_queues to 8 fails, fallback to 1
==================================================================
BUG: KASAN: null-ptr-deref in blk_mq_map_swqueue+0x2f2/0x830
Read of size 8 at addr 0000000000000128 by task nproc/8541

CPU: 5 PID: 8541 Comm: nproc Not tainted 5.7.0-rc4-dbg+ #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-0-gf21b5a4-rebuilt.opensuse.org 04/01/2014
Call Trace:
dump_stack+0xa5/0xe6
__kasan_report.cold+0x65/0xbb
kasan_report+0x45/0x60
check_memory_region+0x15e/0x1c0
__kasan_check_read+0x15/0x20
blk_mq_map_swqueue+0x2f2/0x830
__blk_mq_update_nr_hw_queues+0x3df/0x690
blk_mq_update_nr_hw_queues+0x32/0x50
nullb_device_submit_queues_store+0xde/0x160 [null_blk]
configfs_write_file+0x1c4/0x250 [configfs]
__vfs_write+0x4c/0x90
vfs_write+0x14b/0x2d0
ksys_write+0xdd/0x180
__x64_sys_write+0x47/0x50
do_syscall_64+0x6f/0x310
entry_SYSCALL_64_after_hwframe+0x49/0xb3

Tested-by: Bart van Assche <bvanassche@acm.org>
Signed-off-by: Weiping Zhang <zhangweiping@didiglobal.com>
---
 block/blk-mq.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index bc34d6b572b6..d82cefb0474f 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -3365,8 +3365,8 @@ static void __blk_mq_update_nr_hw_queues(struct blk_mq_tag_set *set,
 		goto reregister;
 
 	set->nr_hw_queues = nr_hw_queues;
-	blk_mq_update_queue_map(set);
 fallback:
+	blk_mq_update_queue_map(set);
 	list_for_each_entry(q, &set->tag_list, tag_set_list) {
 		blk_mq_realloc_hw_ctxs(set, q);
 		if (q->nr_hw_queues != set->nr_hw_queues) {
-- 
2.18.2


^ permalink raw reply related	[flat|nested] 3+ messages in thread
* Re: [PATCH] block: reset mapping if failed to update hardware queue count
  2020-05-13  0:44 [PATCH] block: reset mapping if failed to update hardware queue count Weiping Zhang
@ 2020-05-13  2:20 ` Jens Axboe
  2020-05-13  3:14   ` Weiping Zhang
  0 siblings, 1 reply; 3+ messages in thread
From: Jens Axboe @ 2020-05-13  2:20 UTC (permalink / raw)
  To: bvanassche, tom.leiming, linux-block

On 5/12/20 6:44 PM, Weiping Zhang wrote:
> When we increase hardware queue count, blk_mq_update_queue_map will
> reset the mapping between cpu and hardware queue base on the hardware
> queue count(set->nr_hw_queues). The mapping cannot be reset if it
> encounters error in blk_mq_realloc_hw_ctxs, but the fallback flow will
> continue using it, then blk_mq_map_swqueue will touch a invalid memory,
> because the mapping points to a wrong hctx.
> 
> blktest block/030:
> 
> null_blk: module loaded
> Increasing nr_hw_queues to 8 fails, fallback to 1
> ==================================================================
> BUG: KASAN: null-ptr-deref in blk_mq_map_swqueue+0x2f2/0x830
> Read of size 8 at addr 0000000000000128 by task nproc/8541
> 
> CPU: 5 PID: 8541 Comm: nproc Not tainted 5.7.0-rc4-dbg+ #3
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> rel-1.13.0-0-gf21b5a4-rebuilt.opensuse.org 04/01/2014
> Call Trace:
> dump_stack+0xa5/0xe6
> __kasan_report.cold+0x65/0xbb
> kasan_report+0x45/0x60
> check_memory_region+0x15e/0x1c0
> __kasan_check_read+0x15/0x20
> blk_mq_map_swqueue+0x2f2/0x830
> __blk_mq_update_nr_hw_queues+0x3df/0x690
> blk_mq_update_nr_hw_queues+0x32/0x50
> nullb_device_submit_queues_store+0xde/0x160 [null_blk]
> configfs_write_file+0x1c4/0x250 [configfs]
> __vfs_write+0x4c/0x90
> vfs_write+0x14b/0x2d0
> ksys_write+0xdd/0x180
> __x64_sys_write+0x47/0x50
> do_syscall_64+0x6f/0x310
> entry_SYSCALL_64_after_hwframe+0x49/0xb3

Applied, thanks. Please do run blktests on your series in the future.

-- 
Jens Axboe


^ permalink raw reply	[flat|nested] 3+ messages in thread
* Re: [PATCH] block: reset mapping if failed to update hardware queue count
  2020-05-13  2:20 ` Jens Axboe
@ 2020-05-13  3:14   ` Weiping Zhang
  0 siblings, 0 replies; 3+ messages in thread
From: Weiping Zhang @ 2020-05-13  3:14 UTC (permalink / raw)
  To: Jens Axboe; +Cc: Bart Van Assche, tom.leiming, linux-block

On Wed, May 13, 2020 at 10:22 AM Jens Axboe <axboe@kernel.dk> wrote:
>
> On 5/12/20 6:44 PM, Weiping Zhang wrote:
> > When we increase hardware queue count, blk_mq_update_queue_map will
> > reset the mapping between cpu and hardware queue base on the hardware
> > queue count(set->nr_hw_queues). The mapping cannot be reset if it
> > encounters error in blk_mq_realloc_hw_ctxs, but the fallback flow will
> > continue using it, then blk_mq_map_swqueue will touch a invalid memory,
> > because the mapping points to a wrong hctx.
> >
> > blktest block/030:
> >
> > null_blk: module loaded
> > Increasing nr_hw_queues to 8 fails, fallback to 1
> > ==================================================================
> > BUG: KASAN: null-ptr-deref in blk_mq_map_swqueue+0x2f2/0x830
> > Read of size 8 at addr 0000000000000128 by task nproc/8541
> >
> > CPU: 5 PID: 8541 Comm: nproc Not tainted 5.7.0-rc4-dbg+ #3
> > Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
> > rel-1.13.0-0-gf21b5a4-rebuilt.opensuse.org 04/01/2014
> > Call Trace:
> > dump_stack+0xa5/0xe6
> > __kasan_report.cold+0x65/0xbb
> > kasan_report+0x45/0x60
> > check_memory_region+0x15e/0x1c0
> > __kasan_check_read+0x15/0x20
> > blk_mq_map_swqueue+0x2f2/0x830
> > __blk_mq_update_nr_hw_queues+0x3df/0x690
> > blk_mq_update_nr_hw_queues+0x32/0x50
> > nullb_device_submit_queues_store+0xde/0x160 [null_blk]
> > configfs_write_file+0x1c4/0x250 [configfs]
> > __vfs_write+0x4c/0x90
> > vfs_write+0x14b/0x2d0
> > ksys_write+0xdd/0x180
> > __x64_sys_write+0x47/0x50
> > do_syscall_64+0x6f/0x310
> > entry_SYSCALL_64_after_hwframe+0x49/0xb3
>
> Applied, thanks. Please do run blktests on your series in the future.
>
No problem, thanks a lot.
> --
> Jens Axboe
>

^ permalink raw reply	[flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-05-13  3:14 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-13  0:44 [PATCH] block: reset mapping if failed to update hardware queue count Weiping Zhang
2020-05-13  2:20 ` Jens Axboe
2020-05-13  3:14   ` Weiping Zhang

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.