[bug report] kmemleak observed with blktests nvme-tcp tests

[Sagi Grimberg]

>>> Hello
>>>
>>> Below kmemleak was triggered with blktests nvme-tcp on latest
>>> 5.15.0-rc3, pls check it.
>>>
>>
>> Please share the test number and the frequency to reproduce this...
>>
> 
> Hi
> I'm running the full blktests nvme-tcp[1] and it's 100% reproduced.
> 
> [1]
> # nvme_trtype=tcp ./check nvme/

Yi, this does not happen with nvme_trtype=rdma? It looks like
we don't get to call cdev_device_del and del_gendisk, which means
we may have a referencing problem...

I'm wandering if this is a regression we can bisect to?

> 
>>> unreferenced object 0xffff8882bc8d6668 (size 8):
>>>     comm "kworker/u26:2", pid 82, jiffies 4295107562 (age 2911.554s)
>>>     hex dump (first 8 bytes):
>>>       6e 67 31 6e 31 00 7b 7c                          ng1n1.{|
>>>     backtrace:
>>>       [<0000000046e1c456>] __kmalloc_track_caller+0x129/0x260
>>>       [<00000000a8f7a3a1>] kvasprintf+0xa7/0x120
>>>       [<0000000076a54cc5>] kobject_set_name_vargs+0x41/0x110
>>>       [<00000000a569a16a>] dev_set_name+0x9b/0xd0
>>>       [<00000000f793cc3d>] nvme_mpath_set_live+0x322/0x430 [nvme_core]
>>>       [<000000001f948cbb>] nvme_mpath_add_disk+0x3ef/0x6a0 [nvme_core]
>>>       [<00000000d405af45>] nvme_alloc_ns+0xeb1/0x1ae0 [nvme_core]
>>>       [<000000002fd9b34d>] nvme_validate_or_alloc_ns+0x170/0x350 [nvme_core]
>>>       [<000000009762df74>] nvme_scan_work+0x2dc/0x4b0 [nvme_core]
>>>       [<000000007be5c512>] process_one_work+0x9a8/0x16b0
>>>       [<000000002ae51314>] worker_thread+0x87/0xbf0
>>>       [<0000000034c41079>] kthread+0x371/0x440
>>>       [<0000000020c3a70f>] ret_from_fork+0x22/0x30
>>> unreferenced object 0xffff8882d1509800 (size 512):
>>>     comm "kworker/u26:2", pid 82, jiffies 4295107562 (age 2911.554s)
>>>     hex dump (first 32 bytes):
>>>       00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
>>>       ff ff ff ff ff ff ff ff c0 b6 b7 97 ff ff ff ff  ................
>>>     backtrace:
>>>       [<00000000d6c8d6f1>] kmem_cache_alloc_trace+0x10b/0x220
>>>       [<00000000e6493d28>] device_add+0xe08/0x1d10
>>>       [<00000000aa40e6ce>] cdev_device_add+0xf1/0x150
>>>       [<00000000142436f1>] nvme_cdev_add+0xf8/0x160 [nvme_core]
>>>       [<00000000d948ccab>] nvme_mpath_set_live+0x347/0x430 [nvme_core]
>>>       [<000000001f948cbb>] nvme_mpath_add_disk+0x3ef/0x6a0 [nvme_core]
>>>       [<00000000d405af45>] nvme_alloc_ns+0xeb1/0x1ae0 [nvme_core]
>>>       [<000000002fd9b34d>] nvme_validate_or_alloc_ns+0x170/0x350 [nvme_core]
>>>       [<000000009762df74>] nvme_scan_work+0x2dc/0x4b0 [nvme_core]
>>>       [<000000007be5c512>] process_one_work+0x9a8/0x16b0
>>>       [<000000002ae51314>] worker_thread+0x87/0xbf0
>>>       [<0000000034c41079>] kthread+0x371/0x440
>>>       [<0000000020c3a70f>] ret_from_fork+0x22/0x30
>>>
>>>
>>
>> _______________________________________________
>> Linux-nvme mailing list
>> Linux-nvme at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-nvme
>>
> 
>