[PATCH net] net/mlx5e: Fix XSK pool corruption when switching channels

[PATCH net] net/mlx5e: Fix XSK pool corruption when switching channels

[Tariq Toukan]

From: Gal Pressman <gal@nvidia.com>

When the device supports tis_tir_td_order, mlx5e_safe_switch_params()
closes the old channels only after the new ones are activated.  With an
AF_XDP socket bound, the old and the new channel hold an XSK RQ on the
same pool.

The old RQ returns its buffers to the pool while the new RQ is already
allocating from it. Since the pool is lockless and expects a single user
at a time, it gets out of sync.

Close the old XSK queues before activating the new channels, the rest of
the old channels can still be closed later.

The crash was hit by our regression tests, with a random sequence of
binding xdpsock to every queue and later changing the ring size.

This resolves the following call trace:
  BUG: kernel NULL pointer dereference, address: 0000000000000068
  RIP: 0010:mlx5e_free_rx_mpwqe+0x113/0x250 [mlx5_core]
  Call Trace:
   mlx5e_dealloc_rx_mpwqe+0x38/0xb0 [mlx5_core]
   mlx5e_free_rx_descs+0x126/0x170 [mlx5_core]
   mlx5e_close_rq+0x81/0xb0 [mlx5_core]
   mlx5e_close_channels+0x4b/0xa0 [mlx5_core]
   mlx5e_safe_switch_params+0x34d/0x3e0 [mlx5_core]
   mlx5e_xdp_set+0x287/0x3a0 [mlx5_core]
   dev_xdp_install+0x269/0x400

Fixes: 3b88a535a8e1 ("net/mlx5e: Defer channels closure to reduce interface down time")
Signed-off-by: Gal Pressman <gal@nvidia.com>
Reviewed-by: Nimrod Oren <noren@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
---
 .../net/ethernet/mellanox/mlx5/core/en_main.c | 19 +++++++++++++++++++
 1 file changed, 19 insertions(+)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
index 72bca10c579d..97081a644d5a 100644
--- a/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_main.c
@@ -3421,6 +3421,23 @@ static int mlx5e_switch_priv_params(struct mlx5e_priv *priv,
 	return 0;
 }
 
+/* The old and the new channel of the same index are bound to the same
+ * XSK pool, which is lockless and expects a single user at a time.
+ * Close the old XSK queues before the new ones are activated, even
+ * when the closure of the rest of the old channels is deferred.
+ */
+static void mlx5e_close_channels_xsk(struct mlx5e_channels *chs)
+{
+	int i;
+
+	for (i = 0; i < chs->num; i++) {
+		struct mlx5e_channel *c = chs->c[i];
+
+		if (test_bit(MLX5E_CHANNEL_STATE_XSK, c->state))
+			mlx5e_close_xsk(c);
+	}
+}
+
 static int mlx5e_switch_priv_channels(struct mlx5e_priv *priv,
 				      struct mlx5e_channels *old_chs,
 				      struct mlx5e_channels *new_chs,
@@ -3452,6 +3469,8 @@ static int mlx5e_switch_priv_channels(struct mlx5e_priv *priv,
 	mlx5e_set_xdp_feature(priv);
 	if (!MLX5_CAP_GEN(priv->mdev, tis_tir_td_order))
 		mlx5e_close_channels(old_chs);
+	else
+		mlx5e_close_channels_xsk(old_chs);
 	priv->profile->update_rx(priv);
 
 	mlx5e_selq_apply(&priv->selq);

base-commit: b71c101bbb9814d163c00234d43c41f0a17907d4
-- 
2.44.0

Re: [PATCH net] net/mlx5e: Fix XSK pool corruption when switching channels

[sashiko-bot]

> From: Gal Pressman <gal@nvidia.com>
> 
> When the device supports tis_tir_td_order, mlx5e_safe_switch_params()
> closes the old channels only after the new ones are activated.  With an
> AF_XDP socket bound, the old and the new channel hold an XSK RQ on the
> same pool.
> 
> The old RQ returns its buffers to the pool while the new RQ is already
> allocating from it. Since the pool is lockless and expects a single user
> at a time, it gets out of sync.
> 
> Close the old XSK queues before activating the new channels, the rest of
> the old channels can still be closed later.
> 
> The crash was hit by our regression tests, with a random sequence of
> [ ... ]
> 
> Fixes: 3b88a535a8e1 ("net/mlx5e: Defer channels closure to reduce interface down time")
> Signed-off-by: Gal Pressman <gal@nvidia.com>
> Reviewed-by: Nimrod Oren <noren@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115072934.353341-1-tariqt@nvidia.com?part=1