Kmemleak on nvme-6.5

[Chaitanya Kulkarni]

On 6/3/23 23:38, Chaitanya Kulkarni wrote:
> Sagi,
>
> On 5/16/23 22:35, Chaitanya Kulkarni wrote:
>> Hi,
>>
>> I've observed following kmemleak on nvme-6.5 with blktests
>> nvme/003 HEAD:-
>>
>> nvme (nvme-6.5) # git log
>> commit 851c23be6fc95a48dbdac864f18be63f9a41e8a8 (HEAD -> nvme-6.5,
>> origin/nvme-6.5)
>> Author: Max Gurtovoy <mgurtovoy at nvidia.com>
>> Date:   Tue Apr 25 00:12:42 2023 +0300
>>
>>      nvme: move sysfs code to a dedicated sysfs.c file
>>
>>
>> + cat /sys/kernel/debug/kmemleak
>> unreferenced object 0xffff888114c610c0 (size 96):
>>    comm "insmod", pid 2582, jiffies 4294980741 (age 48.260s)
>>    hex dump (first 32 bytes):
>>      c0 e6 a0 c0 ff ff ff ff 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:
>>      [<00000000430e7112>] kmalloc_trace+0x25/0x90
>>      [<0000000023afbbe3>] class_create+0x21/0x70
>>      [<0000000018569292>] 0xffffffffc0a11039
>>      [<00000000ca4d41aa>] do_one_initcall+0x44/0x220
>>      [<00000000cb8082be>] do_init_module+0x64/0x240
>>      [<000000001b198e51>] __do_sys_finit_module+0xb4/0x130
>>      [<000000003734a6e8>] do_syscall_64+0x3b/0x90
>>      [<000000007e30a8f5>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
>> unreferenced object 0xffff88810a392a00 (size 512):
>>    comm "insmod", pid 2582, jiffies 4294980741 (age 48.260s)
>>    hex dump (first 32 bytes):
>>      00 2a 39 0a 81 88 ff ff 00 2a 39 0a 81 88 ff ff .*9......*9.....
>>      00 00 00 00 00 00 00 00 a0 b3 37 07 81 88 ff ff ..........7.....
>>    backtrace:
>>      [<00000000430e7112>] kmalloc_trace+0x25/0x90
>>      [<00000000ae172de7>] class_register+0x29/0x130
>>      [<0000000035f86164>] class_create+0x3c/0x70
>>      [<0000000018569292>] 0xffffffffc0a11039
>>      [<00000000ca4d41aa>] do_one_initcall+0x44/0x220
>>      [<00000000cb8082be>] do_init_module+0x64/0x240
>>      [<000000001b198e51>] __do_sys_finit_module+0xb4/0x130
>>      [<000000003734a6e8>] do_syscall_64+0x3b/0x90
>>      [<000000007e30a8f5>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
>> unreferenced object 0xffff88810737b3a0 (size 16):
>>    comm "insmod", pid 2582, jiffies 4294980741 (age 48.260s)
>>    hex dump (first 16 bytes):
>>      6e 76 6d 65 2d 66 61 62 72 69 63 73 00 88 ff ff nvme-fabrics....
>>    backtrace:
>>      [<00000000e84e4b63>] __kmalloc_node_track_caller+0x4c/0x130
>>      [<000000000198ce20>] kstrdup+0x33/0x60
>>      [<0000000061fcf661>] kobject_set_name_vargs+0x1e/0x90
>>      [<000000008c34e0dd>] kobject_set_name+0x4e/0x70
>>      [<00000000ae7f3042>] class_register+0x94/0x130
>>      [<0000000035f86164>] class_create+0x3c/0x70
>>      [<0000000018569292>] 0xffffffffc0a11039
>>      [<00000000ca4d41aa>] do_one_initcall+0x44/0x220
>>      [<00000000cb8082be>] do_init_module+0x64/0x240
>>      [<000000001b198e51>] __do_sys_finit_module+0xb4/0x130
>>      [<000000003734a6e8>] do_syscall_64+0x3b/0x90
>>      [<000000007e30a8f5>] entry_SYSCALL_64_after_hwframe+0x72/0xdc
>>
>>
>> For me it is not that straight forward to reproduce that.
>>
>> Thought I should document it.
>>
>> -ck
>
> potential fix could be purely based on code inspection :-
>
> nvme (nvme-6.5) # git diff
> diff --git a/drivers/nvme/host/fabrics.c b/drivers/nvme/host/fabrics.c
> index b1fa27b60917..b8df23b3cba0 100644
> --- a/drivers/nvme/host/fabrics.c
> +++ b/drivers/nvme/host/fabrics.c
> @@ -1410,7 +1410,7 @@ static int __init nvmf_init(void)
>           return 0;
>
>    out_destroy_device:
> -       device_destroy(nvmf_class, MKDEV(0, 0));
> +       device_destroy(nvmf_device, MKDEV(0, 0));
>    out_destroy_class:
>           class_destroy(nvmf_class);
>    out_free_host:
>
>
> Will test above, if it fixes memleak the code will send a patch soon ...
>
> -ck
>
>

ugghh this is wrong, disregard ...

-ck