netdev - RE: [PATCH rdma-next 1/1] RDMA/mana_ib: Set correct device into ib

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] [thread-next>] [day] [month] [year] [list]

Message-ID:
 <CH3PR21MB43989630F6CA822AF3DFB32CCE222@CH3PR21MB4398.namprd21.prod.outlook.com>
Date: Thu, 21 Nov 2024 00:03:41 +0000
From: Long Li <longli@...rosoft.com>
To: Leon Romanovsky <leon@...nel.org>, Konstantin Taranov
	<kotaranov@...rosoft.com>
CC: Konstantin Taranov <kotaranov@...ux.microsoft.com>, Wei Hu
	<weh@...rosoft.com>, "sharmaajay@...rosoft.com" <sharmaajay@...rosoft.com>,
	"jgg@...pe.ca" <jgg@...pe.ca>, "linux-rdma@...r.kernel.org"
	<linux-rdma@...r.kernel.org>, linux-netdev <netdev@...r.kernel.org>, "open
 list:Hyper-V/Azure CORE AND DRIVERS" <linux-hyperv@...r.kernel.org>
Subject: RE: [PATCH rdma-next 1/1] RDMA/mana_ib: Set correct device into ib

> >
> > Actually, another alternative solution for mana_ib is always set the
> > slave device, but in the GID mgmt code we need the following patch.
> > The problem is that it may require testing/confirmation from other ib providers
> as in the worst case some GIDs will not be listed.
> 
> is_eth_active_slave_of_bonding_rcu() is for bonding.

Sorry, need to bring this issue up again.

This patch has broken user-space programs (e.g DPDK) that requires to export a kernel device to user-mode.

With this patch, the RDMA driver grabbed a reference from the master device, it's impossible to move the master device to user-mode.

I think the root cause is that the individual driver should not decide on which (master or slave) address should be used for GID. roce_gid_mgmt.c should handle this situation.

I think Konstantin's suggestion makes sense, how about we do this (don't need to define netdev_is_slave(dev)):

--- a/drivers/infiniband/core/roce_gid_mgmt.c
+++ b/drivers/infiniband/core/roce_gid_mgmt.c
@@ -161,7 +161,7 @@ is_eth_port_of_netdev_filter(struct ib_device *ib_dev, u32 port,
        res = ((rdma_is_upper_dev_rcu(rdma_ndev, cookie) &&
               (is_eth_active_slave_of_bonding_rcu(rdma_ndev, real_dev) &
                REQUIRED_BOND_STATES)) ||
-              real_dev == rdma_ndev);
+              (real_dev == rdma_ndev && !netif_is_bond_slave(rdma_ndev)));

        rcu_read_unlock();
        return res;

is_eth_port_of_netdev_filter() should not return true if this netdev is a bonded slave. In this case, only use the address of its bonded master.

Thanks,

Long