On Wed, Jul 16, 2025 at 6:40 PM Ming Lei <ming.lei@xxxxxxxxxx> wrote: > > On Wed, Jul 16, 2025 at 03:50:34PM +0800, Yu Kuai wrote: > > Hi, > > > > 在 2025/07/16 9:54, Jens Axboe 写道: > > > unreferenced object 0xffff8882e7fbb000 (size 2048): > > > comm "check", pid 10460, jiffies 4324980514 > > > hex dump (first 32 bytes): > > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > > backtrace (crc c47e6a37): > > > __kvmalloc_node_noprof+0x55d/0x7a0 > > > sbitmap_init_node+0x15a/0x6a0 > > > kyber_init_hctx+0x316/0xb90 > > > blk_mq_init_sched+0x416/0x580 > > > elevator_switch+0x18b/0x630 > > > elv_update_nr_hw_queues+0x219/0x2c0 > > > __blk_mq_update_nr_hw_queues+0x36a/0x6f0 > > > blk_mq_update_nr_hw_queues+0x3a/0x60 > > > find_fallback+0x510/0x540 [nbd] > > > > This is werid, and I check the code that it's impossible > > blk_mq_update_nr_hw_queues() can be called from find_fallback(). > > Yes. > > > Does kmemleak show wrong backtrace? > I think so, the kmemleak was observed when I was running all the blktests which include the nbd test, that's why the backtrace have the nbd info. If I only run the test block/040, when the kmemleak occurred, the back trace doesn't have the nbd info now. > I tried to run blktests block/005 over nbd, but can't reproduce this > kmemleak report after setting up the detector. > > Yi, can you share your reproducer? > > > Thanks > Ming > -- Best Regards, Yi Zhang
