Re: [bug report] kmemleak observed with blktests nvme/tcp

[Sagi Grimberg <sagi@xxxxxxxxxxx>]

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?