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 <bsoares.it@gmail.com>
Subject: [PATCH net v3 0/2] net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch
Date: Wed, 16 Sep 2026 11:46:52 +0100 [thread overview]
Message-ID: <20260916104654.31901-1-bsoares.it@gmail.com> (raw)
v3 of "net/mlx5: Bridge, don't fail switchdev events of sibling
eswitch ports" (5f324c5d1b12), addressing review comments on v1/v2:
- Patch 1 fixes the switchdev port-object/attribute notifier filter
(the original fix), and now also covers the LAG bond lower-device
walk used by attribute changes on a bonded uplink
(mlx5_esw_bridge_lower_rep_vport_num_vhca_id_get()), which had the
same ownership gap: it returned the first structurally-eligible
rep found while walking the bond's lower devices, without checking
it's tracked by the calling instance's br_offloads. Since lower
devices are appended in enslavement order, on a merged-eswitch HCA
with a bond spanning reps of more than one eswitch instance, this
could cause a bridge attribute change (ageing time, vlan filtering/
protocol, mcast) to silently no-op on the correct instance. These
two were squashed into one commit per review.
- Patch 2 addresses the reviewer's comment asking whether the peer
unlink path also needed changes: mlx5_esw_bridge_vport_peer_unlink()
lacked the merged_eswitch capability guard that peer_link() already
has, and mlx5_esw_bridge_vport_unlink() itself returned -EINVAL
rather than treating an already-absent/untracked port as a no-op,
which is reachable on a duplicate NETDEV_CHANGEUPPER unlink.
Tested Patch 1 on a ConnectX-7 NIC (MT2910) on my single NIC system.
Patch 2 requires a multiple eswitch instance setup, so I wasn't able
to exercise its code paths.
Note: v1/v2 were sent From/Signed-off-by bersoare@isovalent.com; v3
is sent from my personal address (bsoares.it@gmail.com) instead, for
unrelated mail delivery reasons. Same author, same person.
Bernardo Soares (2):
net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports
net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer
ports
.../mellanox/mlx5/core/en/rep/bridge.c | 45 +++++++++++++++----
.../ethernet/mellanox/mlx5/core/esw/bridge.c | 15 +++++--
.../ethernet/mellanox/mlx5/core/esw/bridge.h | 2 +
3 files changed, 49 insertions(+), 13 deletions(-)
--
2.43.0
next reply other threads:[~2026-09-16 10:47 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-16 10:46 Bernardo Soares [this message]
2026-09-16 10:46 ` [PATCH net v3 1/2] net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports Bernardo Soares
2026-09-16 11:57 ` Mark Bloch
2026-09-16 10:46 ` [PATCH net v3 2/2] net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer ports Bernardo Soares
2026-09-16 11:58 ` Mark Bloch
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=20260916104654.31901-1-bsoares.it@gmail.com \
--to=bsoares.it@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.