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 v4 0/2] net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch
Date: Fri, 18 Sep 2026 10:59:29 +0100 [thread overview]
Message-ID: <20260918095931.29792-1-bsoares.it@gmail.com> (raw)
v4 of "net/mlx5: Bridge, don't fail switchdev events of sibling
eswitch ports" (5f324c5d1b12), addressing reviewer feedback on v3:
- The v3 commit message for patch 1 wrongly attributed the recursive
lower-device walk fix to LAG bond enslavement order. As pointed
out in review, mlx5_esw_bridge_lag_rep_get() already filters on
mlx5_esw_bridge_dev_same_esw() per candidate and cannot select a
sibling's rep. The actual bug is in the generic recursive walk
used when attribute changes are emitted against the bridge master
netdevice directly (a bridge with representors of more than one
eswitch instance enslaved, no LAG involved): the walk returns as
soon as any lower device yields a rep, and the underlying base
case only checks same-HW, not ownership. Commit message rewritten
to describe this correctly; no functional change from v3.
- The v3 commit message for patch 2 claimed a "replayed/duplicate"
NETDEV_CHANGEUPPER unlink as one of the reachable cases. As
pointed out in review, netdevice notifiers are not replayed, so
there is no such duplicate delivery. The actual (and only)
reachable case is a sibling instance whose bridge offload notifier
registers after a peer port was already enslaved, so it misses
the link event and never tracks the port, then genuinely receives
the later unlink event. Commit message rewritten accordingly; no
functional change from v3.
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
and v4 are 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-18 9:59 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-18 9:59 Bernardo Soares [this message]
2026-09-18 9:59 ` [PATCH net v4 1/2] net/mlx5: Bridge, don't fail switchdev events of sibling eswitch ports Bernardo Soares
2026-09-22 6:52 ` Mark Bloch
2026-09-18 9:59 ` [PATCH net v4 2/2] net/mlx5: Bridge, don't fail unlink of untracked/unsupported peer ports Bernardo Soares
2026-09-22 6:52 ` Mark Bloch
2026-09-22 6:42 ` [PATCH net v4 0/2] net/mlx5: Bridge, fix remaining switchdev ownership gaps on merged eswitch Mark Bloch
2026-09-23 1:20 ` patchwork-bot+netdevbpf
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=20260918095931.29792-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox