Re: blktests failures with v6.19 kernel

["yanjun.zhu" <yanjun.zhu@linux.dev>]

On 2/13/26 9:44 AM, Bart Van Assche wrote:
> On 2/12/26 11:57 PM, Shinichiro Kawasaki wrote:
> > [5] kmemleak at nvme/061 wiht rdma transport and siw driver
> >
> > unreferenced object 0xffff888114792600 (size 32):
> >    comm "kworker/2:1H", pid 66, jiffies 4295489358
> >    hex dump (first 32 bytes):
> >      c2 f6 83 05 00 ea ff ff 00 00 00 00 00 10 00 00  ................
> >      00 b0 fd 60 81 88 ff ff 00 10 00 00 00 00 00 00  ...`............
> >    backtrace (crc 3dbac61d):
> >      __kmalloc_noprof+0x62f/0x8b0
> >      sgl_alloc_order+0x74/0x330
> >      0xffffffffc1b73433
> >      0xffffffffc1bc1f0d
> >      0xffffffffc1bc8064
> >      __ib_process_cq+0x14f/0x3e0 [ib_core]
> >      ib_cq_poll_work+0x49/0x160 [ib_core]
> >      process_one_work+0x868/0x1480
> >      worker_thread+0x5ee/0xfd0
> >      kthread+0x3af/0x770
> >      ret_from_fork+0x55c/0x810
> >      ret_from_fork_asm+0x1a/0x30
>
> There are no sgl_alloc() calls in the RDMA subsystem. I think the above
> indicates a memory leak in either the RDMA NVMe target driver or in the
> NVMe target core.

3a2c32d357db RDMA/siw: reclassify sockets in order to avoid false 
positives from lockdep
85cb0757d7e1 net: Convert proto_ops connect() callbacks to use 
sockaddr_unsized
0e50474fa514 net: Convert proto_ops bind() callbacks to use sockaddr_unsized

There are only three commits touching the siw driver between v6.18 and 
v6.19. I therefore suspect the issue is more likely in the NVMe side.

Best Regards,
Zhu Yanjun

> > [7] kmemleak at zbd/009
> >
> > unreferenced object 0xffff88815f1f1280 (size 32):
> >    comm "mount", pid 1745, jiffies 4294866235
> >    hex dump (first 32 bytes):
> >      6d 65 74 61 64 61 74 61 2d 74 72 65 65 6c 6f 67  metadata-treelog
> >      00 93 9c fb af bb ae 00 00 00 00 00 00 00 00 00  ................
> >    backtrace (crc 2ee03cc2):
> >      __kmalloc_node_track_caller_noprof+0x66b/0x8c0
> >      kstrdup+0x42/0xc0
> >      kobject_set_name_vargs+0x44/0x110
> >      kobject_init_and_add+0xcf/0x140
> >      btrfs_sysfs_add_space_info_type+0xf2/0x200 [btrfs]
> >      create_space_info_sub_group.constprop.0+0xfb/0x1b0 [btrfs]
> >      create_space_info+0x247/0x320 [btrfs]
> >      btrfs_init_space_info+0x143/0x1b0 [btrfs]
> >      open_ctree+0x2eed/0x43fe [btrfs]
> >      btrfs_get_tree.cold+0x90/0x1da [btrfs]
> >      vfs_get_tree+0x87/0x2f0
> >      vfs_cmd_create+0xbd/0x280
> >      __do_sys_fsconfig+0x64f/0xa30
> >      do_syscall_64+0x95/0x540
> >      entry_SYSCALL_64_after_hwframe+0x76/0x7e
> > unreferenced object 0xffff888128d80000 (size 16):
> >    comm "mount", pid 1745, jiffies 4294866237
> >    hex dump (first 16 bytes):
> >      64 61 74 61 2d 72 65 6c 6f 63 00 4b 96 f6 48 82  data-reloc.K..H.
> >    backtrace (crc 1598f702):
> >      __kmalloc_node_track_caller_noprof+0x66b/0x8c0
> >      kstrdup+0x42/0xc0
> >      kobject_set_name_vargs+0x44/0x110
> >      kobject_init_and_add+0xcf/0x140
> >      btrfs_sysfs_add_space_info_type+0xf2/0x200 [btrfs]
> >      create_space_info_sub_group.constprop.0+0xfb/0x1b0 [btrfs]
> >      create_space_info+0x211/0x320 [btrfs]
> >      open_ctree+0x2eed/0x43fe [btrfs]
> >      btrfs_get_tree.cold+0x90/0x1da [btrfs]
> >      vfs_get_tree+0x87/0x2f0
> >      vfs_cmd_create+0xbd/0x280
> >      __do_sys_fsconfig+0x64f/0xa30
> >      do_syscall_64+0x95/0x540
> >      entry_SYSCALL_64_after_hwframe+0x76/0x7e
>
> Please report the above to the BTRFS maintainers.
>
> Thanks,
>
> Bart.