From: Bernardo Soares <bsoares.it@gmail.com>
To: Mark Bloch <mbloch@nvidia.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>,
netdev@vger.kernel.org, saeedm@nvidia.com,
Vlad Buslov <vladbu@nvidia.com>,
Bernardo Soares <bersoare@isovalent.com>
Subject: [PATCH net v2 2/3] net/mlx5: LAG, check if vport exists on br_offloads
Date: Mon, 14 Sep 2026 09:54:29 +0100 [thread overview]
Message-ID: <20260914085430.18694-3-bersoare@isovalent.com> (raw)
In-Reply-To: <20260914085430.18694-1-bersoare@isovalent.com>
mlx5_esw_bridge_lower_rep_vport_num_vhca_id_get() walks a LAG bond's
lower devices and returns the first rep that's structurally eligible
(same HCA, is a rep), without checking it's tracked by the calling
instance's br_offloads. On a merged-eswitch HCA where a bond spans
reps of more than one eswitch instance, this can return a sibling's
rep instead of continuing to the one this instance actually owns -
reached via mlx5_esw_bridge_port_obj_attr_set(), so a bridge attribute
change on a bonded uplink can silently no-op on the right instance.
Fix by checking mlx5_esw_bridge_port_exists() at the point each rep is
picked, same as the previous commit did for the single-rep case.
Signed-off-by: Bernardo Soares <bersoare@isovalent.com>
---
v2: new patch, addresses review comment on v1 asking whether
mlx5_esw_bridge_lower_rep_vport_num_vhca_id_get() should verify
the rep it picks while walking a LAG bond's lower devices is
actually tracked by the calling instance's br_offloads, since it
otherwise returns on the first structurally-eligible rep found,
which is not necessarily the one owned by this eswitch instance.
---
.../net/ethernet/mellanox/mlx5/core/en/rep/bridge.c | 13 ++++++++++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/rep/bridge.c b/drivers/net/ethernet/mellanox/mlx5/core/en/rep/bridge.c
index 56592e2e6b9b..4b7b0a0fc2b2 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/rep/bridge.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/rep/bridge.c
@@ -85,9 +85,16 @@ mlx5_esw_bridge_lower_rep_vport_num_vhca_id_get(struct net_device *dev, struct m
struct net_device *lower_dev;
struct list_head *iter;
- if (netif_is_lag_master(dev) || mlx5e_eswitch_rep(dev))
- return mlx5_esw_bridge_rep_vport_num_vhca_id_get(dev, esw, vport_num,
- esw_owner_vhca_id);
+ if (netif_is_lag_master(dev) || mlx5e_eswitch_rep(dev)) {
+ struct net_device *rep;
+
+ rep = mlx5_esw_bridge_rep_vport_num_vhca_id_get(dev, esw, vport_num,
+ esw_owner_vhca_id);
+ if (rep && !mlx5_esw_bridge_port_exists(*vport_num, *esw_owner_vhca_id,
+ esw->br_offloads))
+ return NULL;
+ return rep;
+ }
netdev_for_each_lower_dev(dev, lower_dev, iter) {
struct net_device *rep;
--
2.43.0
next prev parent reply other threads:[~2026-09-14 8:55 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-08 16:19 [PATCH net] net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports Daniel Borkmann
2026-09-10 12:47 ` Mark Bloch
2026-09-14 8:54 ` [PATCH net v2 0/3] net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch Bernardo Soares
2026-09-14 8:54 ` [PATCH net v2 1/3] net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports Bernardo Soares
2026-09-17 2:56 ` netdev-bot+sashiko
2026-09-14 8:54 ` Bernardo Soares [this message]
2026-09-15 19:52 ` [PATCH net v2 2/3] net/mlx5: LAG, check if vport exists on br_offloads Mark Bloch
2026-09-17 2:56 ` netdev-bot+sashiko
2026-09-14 8:54 ` [PATCH net v2 3/3] net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer ports Bernardo Soares
2026-09-15 19:51 ` Mark Bloch
2026-09-17 2:56 ` netdev-bot+sashiko
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260914085430.18694-3-bersoare@isovalent.com \
--to=bsoares.it@gmail.com \
--cc=bersoare@isovalent.com \
--cc=daniel@iogearbox.net \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=saeedm@nvidia.com \
--cc=vladbu@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox