Kmemleak on nvme-6.5

[Sagi Grimberg]

> 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

I'm assuming this is not the result of a bisect correct?

> 
> 
> + 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.

Looks outside of nvme to me...