On Wed, May 13, 2020 at 10:22 AM Jens Axboe <axboe@xxxxxxxxx> 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 >
