blktests nvme 041,042 leak memory

[Maurizio Lombardi]

This happens because if the nvme_init_ctrl() function fails, the
callers assume that put_device() isn't necessary
and just execute kfree() against the ctrl structure.

This patch fixes the problem for TCP, it should also work for loop but
I've not tested it.

http://bsdbackstore.eu/misc/0001-nvme-fix-memory-leak-when-nvme_init_ctrl-fails.patch

-- 
2.43.0

po 27. 5. 2024 v 3:12 odesílatel Yi Zhang <yi.zhang at redhat.com> napsal:
>
> Yeah, I also met this leak during nvme/044
>
> https://lore.kernel.org/linux-nvme/CAHj4cs-jM_46qK2n3g9vFguq7LVBSm1h38b6Sg_j5veubontWw@mail.gmail.com/
>
> On Mon, May 27, 2024 at 3:49 AM Sagi Grimberg <sagi at grimberg.me> wrote:
> >
> > Just noticed that these tests generate a kmemleak complaint.
> >
> > --
> > [ 1889.516324] kmemleak: 2 new suspected memory leaks (see
> > /sys/kernel/debug/kmemleak)
> > [13221.498042] loop6: detected capacity change from 0 to 8
> > ^C
> > root at nvme:~# cat /sys/kernel/debug/kmemleak
> > unreferenced object 0xffff91488fb07200 (size 256):
> >    comm "nvme", pid 29344, jiffies 4295069699
> >    hex dump (first 32 bytes):
> >      00 00 00 00 00 00 00 00 08 72 b0 8f 48 91 ff ff .........r..H...
> >      08 72 b0 8f 48 91 ff ff 00 d6 55 a2 ff ff ff ff .r..H.....U.....
> >    backtrace (crc 36f6c278):
> >      [<ffffffffa2b8b46a>] kmemleak_alloc+0x4a/0x90
> >      [<ffffffffa1e57897>] kmalloc_trace+0x2f7/0x3a0
> >      [<ffffffffa2562fd0>] device_add+0x510/0x8c0
> >      [<ffffffffa1ee5b9e>] cdev_device_add+0x4e/0xc0
> >      [<ffffffffc133b7a0>] nvme_init_ctrl+0x360/0x460 [nvme_core]
> >      [<ffffffffc13b0af6>] 0xffffffffc13b0af6
> >      [<ffffffffc120e565>] 0xffffffffc120e565
> >      [<ffffffffa1edeb14>] vfs_write+0x104/0x490
> >      [<ffffffffa1edf263>] ksys_write+0x73/0x100
> >      [<ffffffffa1edf319>] __x64_sys_write+0x19/0x30
> >      [<ffffffffa1a0553e>] x64_sys_call+0x7e/0x25c0
> >      [<ffffffffa2b7be01>] do_syscall_64+0x71/0x130
> >      [<ffffffffa2c0012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > unreferenced object 0xffff91488ed7ea00 (size 256):
> >    comm "nvme", pid 37478, jiffies 4295155857
> >    hex dump (first 32 bytes):
> >      00 00 00 00 00 00 00 00 08 ea d7 8e 48 91 ff ff ............H...
> >      08 ea d7 8e 48 91 ff ff 00 d6 55 a2 ff ff ff ff ....H.....U.....
> >    backtrace (crc fc1acf5):
> >      [<ffffffffa2b8b46a>] kmemleak_alloc+0x4a/0x90
> >      [<ffffffffa1e57897>] kmalloc_trace+0x2f7/0x3a0
> >      [<ffffffffa2562fd0>] device_add+0x510/0x8c0
> >      [<ffffffffa1ee5b9e>] cdev_device_add+0x4e/0xc0
> >      [<ffffffffc133b7a0>] nvme_init_ctrl+0x360/0x460 [nvme_core]
> >      [<ffffffffc13707b7>] 0xffffffffc13707b7
> >      [<ffffffffc120e565>] 0xffffffffc120e565
> >      [<ffffffffa1edeb14>] vfs_write+0x104/0x490
> >      [<ffffffffa1edf263>] ksys_write+0x73/0x100
> >      [<ffffffffa1edf319>] __x64_sys_write+0x19/0x30
> >      [<ffffffffa1a0553e>] x64_sys_call+0x7e/0x25c0
> >      [<ffffffffa2b7be01>] do_syscall_64+0x71/0x130
> >      [<ffffffffa2c0012b>] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > --
> >
> > The culprit is when failing after device_initialize/cdev_device_add...
> > Thought I'd share it as I'm not going to address it today.
> >
>
>
> --
> Best Regards,
>   Yi Zhang
>
>