On Sun, Apr 21, 2024 at 6:31 PM Sagi Grimberg <sagi@xxxxxxxxxxx> wrote: > > > > On 16/04/2024 6:19, Chaitanya Kulkarni wrote: > > +linux-nvme list for awareness ... > > > > -ck > > > > > > On 4/6/24 17:38, Yi Zhang wrote: > >> Hello > >> > >> I found the kmemleak issue after blktests nvme/tcp tests on the latest > >> linux-block/for-next, please help check it and let me know if you need > >> any info/testing for it, thanks. > > it will help others to specify which testcase you are using ... > > > >> # dmesg | grep kmemleak > >> [ 2580.572467] kmemleak: 92 new suspected memory leaks (see > >> /sys/kernel/debug/kmemleak) > >> > >> # cat kmemleak.log > >> unreferenced object 0xffff8885a1abe740 (size 32): > >> comm "kworker/40:1H", pid 799, jiffies 4296062986 > >> hex dump (first 32 bytes): > >> c2 4a 4a 04 00 ea ff ff 00 00 00 00 00 10 00 00 .JJ............. > >> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > >> backtrace (crc 6328eade): > >> [<ffffffffa7f2657c>] __kmalloc+0x37c/0x480 > >> [<ffffffffa86a9b1f>] sgl_alloc_order+0x7f/0x360 > >> [<ffffffffc261f6c5>] lo_read_simple+0x1d5/0x5b0 [loop] > >> [<ffffffffc26287ef>] 0xffffffffc26287ef > >> [<ffffffffc262a2c4>] 0xffffffffc262a2c4 > >> [<ffffffffc262a881>] 0xffffffffc262a881 > >> [<ffffffffa76adf3c>] process_one_work+0x89c/0x19f0 > >> [<ffffffffa76b0813>] worker_thread+0x583/0xd20 > >> [<ffffffffa76ce2a3>] kthread+0x2f3/0x3e0 > >> [<ffffffffa74a804d>] ret_from_fork+0x2d/0x70 > >> [<ffffffffa7406e4a>] ret_from_fork_asm+0x1a/0x30 > >> unreferenced object 0xffff88a8b03647c0 (size 16): > >> comm "kworker/40:1H", pid 799, jiffies 4296062986 > >> hex dump (first 16 bytes): > >> c0 4a 4a 04 00 ea ff ff 00 10 00 00 00 00 00 00 .JJ............. > >> backtrace (crc 860ce62b): > >> [<ffffffffa7f2657c>] __kmalloc+0x37c/0x480 > >> [<ffffffffc261f805>] lo_read_simple+0x315/0x5b0 [loop] > >> [<ffffffffc26287ef>] 0xffffffffc26287ef > >> [<ffffffffc262a2c4>] 0xffffffffc262a2c4 > >> [<ffffffffc262a881>] 0xffffffffc262a881 > >> [<ffffffffa76adf3c>] process_one_work+0x89c/0x19f0 > >> [<ffffffffa76b0813>] worker_thread+0x583/0xd20 > >> [<ffffffffa76ce2a3>] kthread+0x2f3/0x3e0 > >> [<ffffffffa74a804d>] ret_from_fork+0x2d/0x70 > >> [<ffffffffa7406e4a>] ret_from_fork_asm+0x1a/0x30 > > kmemleak suggest that the leakage is coming from lo_read_simple() Is > this a regression that can be bisected? > It's not one regression issue, I tried 6.7 and it also can be reproduced. -- Best Regards, Yi Zhang
