From: Tariq Toukan <tariqt@nvidia.com>
To: Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, <netdev@vger.kernel.org>,
Paolo Abeni <pabeni@redhat.com>
Cc: Cosmin Ratiu <cratiu@nvidia.com>,
Leon Romanovsky <leon@kernel.org>, <linux-kernel@vger.kernel.org>,
<linux-rdma@vger.kernel.org>, Mark Bloch <mbloch@nvidia.com>,
Saeed Mahameed <saeedm@nvidia.com>, Shay Drory <shayd@nvidia.com>,
Tariq Toukan <tariqt@nvidia.com>
Subject: [PATCH net] net/mlx5e: TC, Check if flow is PEER before acquiring devcom lock
Date: Fri, 17 Jul 2026 10:30:41 +0300 [thread overview]
Message-ID: <20260717073041.1241894-1-tariqt@nvidia.com> (raw)
From: Shay Drory <shayd@nvidia.com>
In case __mlx5e_add_fdb_flow() fails in lower levels, the flow is
deleted via mlx5e_tc_del_flow(), and mlx5e_tc_del_flow() is acquiring
ESW devcom lock without condition. In addition, in case of peer_flow,
__mlx5e_add_fdb_flow() is called while holding ESW devcom comp lock.
This results in an AA deadlock.
To fix this, introduce a new PEER flag that is set on flows created as
peer flows (the duplicate flows on peer devices), and check it in
mlx5e_tc_del_flow() before acquiring ESW devcom lock.
In addition, rename the existing DUP flag to PRIMARY to better reflect
its semantics. The DUP flag indicated that a flow has peer flows on
other devices, but the name was not descriptive. PRIMARY clearly
indicates this is the original flow that manages peer flows.
This makes the distinction between the two flow roles explicit:
- PRIMARY: the original flow that owns and manages peer flows
- PEER: the duplicate flows created on peer devices
Lockdep splat:
============================================
WARNING: possible recursive locking detected
============================================
Possible unsafe locking scenario:
CPU0
----
lock(&comp->lock_key#2);
lock(&comp->lock_key#2);
*** DEADLOCK ***
Call Trace:
<TASK>
dump_stack_lvl+0x69/0xa0
print_deadlock_bug.cold+0xbd/0xca
__lock_acquire+0x1671/0x2ec0
lock_acquire+0x10e/0x2e0
down_read+0x95/0x430
mlx5_devcom_for_each_peer_begin+0x4e/0xe0 [mlx5_core]
mlx5e_tc_del_flow+0x11d/0xa70 [mlx5_core]
mlx5e_flow_put+0x99/0x100 [mlx5_core]
__mlx5e_add_fdb_flow+0x409/0xf00 [mlx5_core]
mlx5e_configure_flower+0x2a86/0x4100 [mlx5_core]
mlx5e_rep_setup_tc_cls_flower+0x12f/0x1b0 [mlx5_core]
mlx5e_rep_setup_tc_cb+0x153/0x750 [mlx5_core]
tc_setup_cb_add+0x1dc/0x470
fl_change+0x2f4d/0x626d [cls_flower]
tc_new_tfilter+0x79b/0x2310
rtnetlink_rcv_msg+0x778/0xad0
do_syscall_64+0x70/0x960
entry_SYSCALL_64_after_hwframe+0x4b/0x53
</TASK>
Fixes: 04de7dda7394 ("net/mlx5e: Infrastructure for duplicated offloading of TC flows")
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Cosmin Ratiu <cratiu@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 4 +++-
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h
index 28cab4bf525c..7bfe7cdc5770 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en/tc_priv.h
@@ -30,6 +30,7 @@ enum {
MLX5E_TC_FLOW_FLAG_FAILED = MLX5E_TC_FLOW_BASE + 9,
MLX5E_TC_FLOW_FLAG_SAMPLE = MLX5E_TC_FLOW_BASE + 10,
MLX5E_TC_FLOW_FLAG_USE_ACT_STATS = MLX5E_TC_FLOW_BASE + 11,
+ MLX5E_TC_FLOW_FLAG_PEER = MLX5E_TC_FLOW_BASE + 12,
};
struct mlx5e_tc_flow_parse_attr {
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 1bc7b9019124..b290beb4369a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -2161,7 +2161,8 @@ static void mlx5e_tc_del_flow(struct mlx5e_priv *priv,
if (mlx5e_is_eswitch_flow(flow)) {
struct mlx5_devcom_comp_dev *devcom = flow->priv->mdev->priv.eswitch->devcom;
- if (!mlx5_devcom_for_each_peer_begin(devcom)) {
+ if (flow_flag_test(flow, PEER) ||
+ !mlx5_devcom_for_each_peer_begin(devcom)) {
mlx5e_tc_del_fdb_flow(priv, flow);
return;
}
@@ -4628,6 +4629,7 @@ static int mlx5e_tc_add_fdb_peer_flow(struct flow_cls_offload *f,
else
in_mdev = priv->mdev;
+ flow_flags |= BIT(MLX5E_TC_FLOW_FLAG_PEER);
parse_attr = flow->attr->parse_attr;
peer_flow = __mlx5e_add_fdb_flow(peer_priv, f, flow_flags,
parse_attr->filter_dev,
base-commit: 3f1f755366687d051174739fb99f7d560202f60b
--
2.44.0
reply other threads:[~2026-07-17 7:31 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20260717073041.1241894-1-tariqt@nvidia.com \
--to=tariqt@nvidia.com \
--cc=andrew+netdev@lunn.ch \
--cc=cratiu@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=mbloch@nvidia.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=saeedm@nvidia.com \
--cc=shayd@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