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
