[bug report] kmemleak observed with blktests nvme/tcp

[Sagi Grimberg]

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?