From: Saeed Mahameed <saeed@kernel.org>
To: "David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Eric Dumazet <edumazet@google.com>
Cc: Saeed Mahameed <saeedm@nvidia.com>,
netdev@vger.kernel.org, Tariq Toukan <tariqt@nvidia.com>,
Paul Blakey <paulb@nvidia.com>, Chris Mi <cmi@nvidia.com>,
Roi Dayan <roid@nvidia.com>
Subject: [net V2 07/14] net/mlx5e: Fix cleanup null-ptr deref on encap lock
Date: Wed, 15 Mar 2023 15:58:40 -0700 [thread overview]
Message-ID: <20230315225847.360083-8-saeed@kernel.org> (raw)
In-Reply-To: <20230315225847.360083-1-saeed@kernel.org>
From: Paul Blakey <paulb@nvidia.com>
During module is unloaded while a peer tc flow is still offloaded,
first the peer uplink rep profile is changed to a nic profile, and so
neigh encap lock is destroyed. Next during unload, the VF reps netdevs
are unregistered which causes the original non-peer tc flow to be deleted,
which deletes the peer flow. The peer flow deletion detaches the encap
entry and try to take the already destroyed encap lock, causing the
below trace.
Fix this by clearing peer flows during tc eswitch cleanup
(mlx5e_tc_esw_cleanup()).
Relevant trace:
[ 4316.837128] BUG: kernel NULL pointer dereference, address: 00000000000001d8
[ 4316.842239] RIP: 0010:__mutex_lock+0xb5/0xc40
[ 4316.851897] Call Trace:
[ 4316.852481] <TASK>
[ 4316.857214] mlx5e_rep_neigh_entry_release+0x93/0x790 [mlx5_core]
[ 4316.858258] mlx5e_rep_encap_entry_detach+0xa7/0xf0 [mlx5_core]
[ 4316.859134] mlx5e_encap_dealloc+0xa3/0xf0 [mlx5_core]
[ 4316.859867] clean_encap_dests.part.0+0x5c/0xe0 [mlx5_core]
[ 4316.860605] mlx5e_tc_del_fdb_flow+0x32a/0x810 [mlx5_core]
[ 4316.862609] __mlx5e_tc_del_fdb_peer_flow+0x1a2/0x250 [mlx5_core]
[ 4316.863394] mlx5e_tc_del_flow+0x(/0x630 [mlx5_core]
[ 4316.864090] mlx5e_flow_put+0x5f/0x100 [mlx5_core]
[ 4316.864771] mlx5e_delete_flower+0x4de/0xa40 [mlx5_core]
[ 4316.865486] tc_setup_cb_reoffload+0x20/0x80
[ 4316.865905] fl_reoffload+0x47c/0x510 [cls_flower]
[ 4316.869181] tcf_block_playback_offloads+0x91/0x1d0
[ 4316.869649] tcf_block_unbind+0xe7/0x1b0
[ 4316.870049] tcf_block_offload_cmd.isra.0+0x1ee/0x270
[ 4316.879266] tcf_block_offload_unbind+0x61/0xa0
[ 4316.879711] __tcf_block_put+0xa4/0x310
Fixes: 04de7dda7394 ("net/mlx5e: Infrastructure for duplicated offloading of TC flows")
Fixes: 1418ddd96afd ("net/mlx5e: Duplicate offloaded TC eswitch rules under uplink LAG")
Signed-off-by: Paul Blakey <paulb@nvidia.com>
Reviewed-by: Chris Mi <cmi@nvidia.com>
Reviewed-by: Roi Dayan <roid@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
---
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
index 90944bf271ce..cc35cbc9934d 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_tc.c
@@ -5464,6 +5464,16 @@ int mlx5e_tc_esw_init(struct mlx5_rep_uplink_priv *uplink_priv)
void mlx5e_tc_esw_cleanup(struct mlx5_rep_uplink_priv *uplink_priv)
{
+ struct mlx5e_rep_priv *rpriv;
+ struct mlx5_eswitch *esw;
+ struct mlx5e_priv *priv;
+
+ rpriv = container_of(uplink_priv, struct mlx5e_rep_priv, uplink_priv);
+ priv = netdev_priv(rpriv->netdev);
+ esw = priv->mdev->priv.eswitch;
+
+ mlx5e_tc_clean_fdb_peer_flows(esw);
+
mlx5e_tc_tun_cleanup(uplink_priv->encap);
mapping_destroy(uplink_priv->tunnel_enc_opts_mapping);
--
2.39.2
next prev parent reply other threads:[~2023-03-15 22:59 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-15 22:58 [pull request][net V2 00/14] mlx5 fixes 2023-03-15 Saeed Mahameed
2023-03-15 22:58 ` [net V2 01/14] net/mlx5e: Fix macsec ASO context alignment Saeed Mahameed
2023-03-17 4:30 ` patchwork-bot+netdevbpf
2023-03-15 22:58 ` [net V2 02/14] net/mlx5e: Don't cache tunnel offloads capability Saeed Mahameed
2023-03-15 22:58 ` [net V2 03/14] net/mlx5: Fix setting ec_function bit in MANAGE_PAGES Saeed Mahameed
2023-03-15 22:58 ` [net V2 04/14] net/mlx5: Disable eswitch before waiting for VF pages Saeed Mahameed
2023-03-15 22:58 ` [net V2 05/14] net/mlx5: E-switch, Fix wrong usage of source port rewrite in split rules Saeed Mahameed
2023-03-15 22:58 ` [net V2 06/14] net/mlx5: E-switch, Fix missing set of split_count when forward to ovs internal port Saeed Mahameed
2023-03-15 22:58 ` Saeed Mahameed [this message]
2023-03-15 22:58 ` [net V2 08/14] net/mlx5e: kTLS, Fix missing error unwind on unsupported cipher type Saeed Mahameed
2023-03-15 22:58 ` [net V2 09/14] net/mlx5: Set BREAK_FW_WAIT flag first when removing driver Saeed Mahameed
2023-03-15 22:58 ` [net V2 10/14] net/mlx5e: Lower maximum allowed MTU in XSK to match XDP prerequisites Saeed Mahameed
2023-03-15 22:58 ` [net V2 11/14] net/sched: TC, fix raw counter initialization Saeed Mahameed
2023-03-15 22:58 ` [net V2 12/14] net/mlx5e: TC, fix missing error code Saeed Mahameed
2023-03-15 22:58 ` [net V2 13/14] net/mlx5e: TC, fix cloned flow attribute Saeed Mahameed
2023-03-15 22:58 ` [net V2 14/14] net/mlx5e: TC, Remove error message log print Saeed Mahameed
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=20230315225847.360083-8-saeed@kernel.org \
--to=saeed@kernel.org \
--cc=cmi@nvidia.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=paulb@nvidia.com \
--cc=roid@nvidia.com \
--cc=saeedm@nvidia.com \
--cc=tariqt@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;
as well as URLs for NNTP newsgroup(s).