linux-kernel - RE: [rdma bug] del_default_gids() is not called upon NETDEV

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
 <SJ0PR12MB6806E77B849859B7BAC8CC1CDC89A@SJ0PR12MB6806.namprd12.prod.outlook.com>
Date: Tue, 20 Jan 2026 11:43:46 +0000
From: Parav Pandit <parav@...lanox.com>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>, Huy Nguyen
	<huyn@...dia.com>, Jason Gunthorpe <jgg@...pe.ca>, Leon Romanovsky
	<leon@...nel.org>, Maher Sanalla <msanalla@...dia.com>, Maor Gottlieb
	<maorg@...dia.com>
CC: OFED mailing list <linux-rdma@...r.kernel.org>, LKML
	<linux-kernel@...r.kernel.org>
Subject: RE: [rdma bug] del_default_gids() is not called upon
 NETDEV_UNREGISTER event


> From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
> Sent: 20 January 2026 03:29 PM
> 
> Hello.
> 
> syzbot found in linux-next-20260116 that one of causes that appear as
> 
>   unregister_netdevice: waiting for bond1 to become free. Usage count = 2
> 
> problem ( https://syzkaller.appspot.com/bug?extid=881d65229ca4f9ae8c84 ) is that
> a refcount for "struct ib_gid_table_entry" is leaking because del_default_gids()
> is not called upon NETDEV_UNREGISTER event; a debug printk() patch revealed that
> only add_default_gids() was called.
> 
> Since "struct ib_gid_table_entry" takes a reference to "struct net_device" via
> "struct roce_gid_ndev_storage", the corresponding NETDEV_UNREGISTER handler
> must release that reference. Something was overlooked when writing commit
> 943bd984b108 ("RDMA/core: Allow detaching gid attribute netdevice for RoCE") ?
> 
It is unlikely this commit.
My suspect is the bug that you reported in [1] is the cause, i.e. the ib device REGISTERED and netdev event racing.
However, flushing the wq does not seem the robust solution either because right after flushing the netdev unregister event may arrive.

I haven’t thought through fully or analyse the code recently, 
gid_table_cleanup_one() should cleanup and release the reference anyway.
If that is done correctly, the reference is held somewhere else.
Isn’t it?

[1] https://lore.kernel.org/all/10caea5b-9ad1-44ce-9eaf-a0f4023f2017@I-love.SAKURA.ne.jp/T/#m8fa52610b102c8ae53e65a1af92d410274c0d583

> 
> unregister_netdevice: waiting for bond1 to become free. Usage count = 2
> Call trace for bond1@...f888043434a00 +1 at
>      alloc_gid_entry drivers/infiniband/core/cache.c:417 [inline]
>      add_modify_gid+0x317/0xcc0 drivers/infiniband/core/cache.c:557
>      __ib_cache_gid_add+0x230/0x370 drivers/infiniband/core/cache.c:688
>      ib_cache_gid_set_default_gid+0x5f9/0x710 drivers/infiniband/core/cache.c:967
>      add_default_gids drivers/infiniband/core/roce_gid_mgmt.c:492 [inline]
>      enum_all_gids_of_dev_cb+0x17d/0x270 drivers/infiniband/core/roce_gid_mgmt.c:518
>      ib_enum_roce_netdev+0x1ab/0x2e0 drivers/infiniband/core/device.c:2434
>      gid_table_setup_one drivers/infiniband/core/cache.c:1040 [inline]
>      ib_cache_setup_one+0x428/0x5e0 drivers/infiniband/core/cache.c:1719
>      ib_register_device+0xfbe/0x1420 drivers/infiniband/core/device.c:1450
>      rxe_register_device+0x1e3/0x350 drivers/infiniband/sw/rxe/rxe_verbs.c:1556
>      rxe_net_add+0x81/0x110 drivers/infiniband/sw/rxe/rxe_net.c:618
>      rxe_newlink+0xdd/0x190 drivers/infiniband/sw/rxe/rxe.c:234
>      nldev_newlink+0x4a5/0x5a0 drivers/infiniband/core/nldev.c:1797
>      rdma_nl_rcv_msg drivers/infiniband/core/netlink.c:-1 [inline]
>      rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline]
>      rdma_nl_rcv+0x6ae/0x980 drivers/infiniband/core/netlink.c:259
>      netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
>      netlink_unicast+0x82f/0x9e0 net/netlink/af_netlink.c:1344
>      netlink_sendmsg+0x805/0xb30 net/netlink/af_netlink.c:1894
>      sock_sendmsg_nosec+0x18f/0x1d0 net/socket.c:737
> Call trace for bond1@...f888043434a00 +1 at
>      get_gid_entry drivers/infiniband/core/cache.c:442 [inline]
>      rdma_get_gid_attr+0x2ee/0x3f0 drivers/infiniband/core/cache.c:1307
>      smc_ib_fill_mac net/smc/smc_ib.c:160 [inline]
>      smc_ib_remember_port_attr net/smc/smc_ib.c:369 [inline]
>      smc_ib_port_event_work+0x196/0x940 net/smc/smc_ib.c:388
>      process_one_work+0x93a/0x15a0 kernel/workqueue.c:3279
> Call trace for bond1@...f888043434a00 -1 at
>      put_gid_entry drivers/infiniband/core/cache.c:448 [inline]
>      rdma_put_gid_attr+0x7c/0x130 drivers/infiniband/core/cache.c:1388
>      smc_ib_fill_mac net/smc/smc_ib.c:165 [inline]
>      smc_ib_remember_port_attr net/smc/smc_ib.c:369 [inline]
>      smc_ib_port_event_work+0x1d4/0x940 net/smc/smc_ib.c:388
>      process_one_work+0x93a/0x15a0 kernel/workqueue.c:3279
> Call trace for bond1@...f888043434a00 +1 !NETREG_REGISTERED at
>      get_gid_entry drivers/infiniband/core/cache.c:442 [inline]
>      rdma_get_gid_attr+0x2ee/0x3f0 drivers/infiniband/core/cache.c:1307
>      smc_ib_fill_mac net/smc/smc_ib.c:160 [inline]
>      smc_ib_remember_port_attr net/smc/smc_ib.c:369 [inline]
>      smc_ib_port_event_work+0x196/0x940 net/smc/smc_ib.c:388
>      process_one_work+0x93a/0x15a0 kernel/workqueue.c:3279
> Call trace for bond1@...f888043434a00 -1 !NETREG_REGISTERED at
>      put_gid_entry drivers/infiniband/core/cache.c:448 [inline]
>      rdma_put_gid_attr+0x7c/0x130 drivers/infiniband/core/cache.c:1388
>      smc_ib_fill_mac net/smc/smc_ib.c:165 [inline]
>      smc_ib_remember_port_attr net/smc/smc_ib.c:369 [inline]
>      smc_ib_port_event_work+0x1d4/0x940 net/smc/smc_ib.c:388
>      process_one_work+0x93a/0x15a0 kernel/workqueue.c:3279
> infiniband: balance for bond1@...gid_table_entry is 1