* Kmemleak on nvme-6.5
@ 2023-05-17 5:35 Chaitanya Kulkarni
2023-05-17 7:47 ` Sagi Grimberg
2023-06-04 6:38 ` Chaitanya Kulkarni
0 siblings, 2 replies; 5+ messages in thread
From: Chaitanya Kulkarni @ 2023-05-17 5:35 UTC (permalink / raw)
To: linux-nvme
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@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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Kmemleak on nvme-6.5
2023-05-17 5:35 Kmemleak on nvme-6.5 Chaitanya Kulkarni
@ 2023-05-17 7:47 ` Sagi Grimberg
2023-05-17 7:51 ` Chaitanya Kulkarni
2023-06-04 6:38 ` Chaitanya Kulkarni
1 sibling, 1 reply; 5+ messages in thread
From: Sagi Grimberg @ 2023-05-17 7:47 UTC (permalink / raw)
To: Chaitanya Kulkarni, linux-nvme
> 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@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...
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Kmemleak on nvme-6.5
2023-05-17 7:47 ` Sagi Grimberg
@ 2023-05-17 7:51 ` Chaitanya Kulkarni
0 siblings, 0 replies; 5+ messages in thread
From: Chaitanya Kulkarni @ 2023-05-17 7:51 UTC (permalink / raw)
To: Sagi Grimberg, linux-nvme
On 5/17/23 00:47, Sagi Grimberg 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@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?
no it's current head on which I ran blktests ..
-ck
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Kmemleak on nvme-6.5
2023-05-17 5:35 Kmemleak on nvme-6.5 Chaitanya Kulkarni
2023-05-17 7:47 ` Sagi Grimberg
@ 2023-06-04 6:38 ` Chaitanya Kulkarni
2023-06-04 6:42 ` Chaitanya Kulkarni
1 sibling, 1 reply; 5+ messages in thread
From: Chaitanya Kulkarni @ 2023-06-04 6:38 UTC (permalink / raw)
To: Sagi Grimberg; +Cc: linux-nvme
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@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
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: Kmemleak on nvme-6.5
2023-06-04 6:38 ` Chaitanya Kulkarni
@ 2023-06-04 6:42 ` Chaitanya Kulkarni
0 siblings, 0 replies; 5+ messages in thread
From: Chaitanya Kulkarni @ 2023-06-04 6:42 UTC (permalink / raw)
To: Sagi Grimberg; +Cc: linux-nvme
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@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
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-06-04 6:42 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-17 5:35 Kmemleak on nvme-6.5 Chaitanya Kulkarni
2023-05-17 7:47 ` Sagi Grimberg
2023-05-17 7:51 ` Chaitanya Kulkarni
2023-06-04 6:38 ` Chaitanya Kulkarni
2023-06-04 6:42 ` Chaitanya Kulkarni
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).