[bug report] kmemleak observed with blktests nvme/tcp

[Yi Zhang]

On Sun, Apr 21, 2024 at 6:31 PM Sagi Grimberg <sagi at grimberg.me> 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