Kmemleak on nvme-6.5

[Chaitanya Kulkarni]

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