Re: [PATCH 1/2] net/mlx5e: kTLS: reject stale RX queue mapping on RX offload setup

On 16/07/2026 11:35, Tariq Toukan wrote:

On 15/07/2026 1:29, Rishikesh Jethwani wrote:

quoted

mlx5e_ktls_sk_get_rxq() treats only the -1 sentinel from
sk_rx_queue_get() as special and returns all other values unchanged.

After 'ethtool -L <dev> combined N' reduces the number of channels, a
socket can retain an sk_rx_queue_mapping from the previous
configuration that is no longer valid for the current
priv->channels.num. If TLS RX offload is then enabled for that socket,
mlx5e_ktls_add_rx() uses the stale queue index and can access a
channel outside the current array.

Preserve the existing -1 -> 0 fallback for sockets that do not yet
have a recorded RX queue, but reject queue indices that are outside
the current channel range and fail setup with -EINVAL instead. Wire
the failure through the existing err_create_tir unwind so resources
allocated earlier in mlx5e_ktls_add_rx() are released cleanly.

This addresses stale queue mappings during RX offload setup. Existing
offloaded sockets whose channel disappears after reconfiguration are
handled separately in the resync path.

Fixes: 1182f3659357 ("net/mlx5e: kTLS, Add kTLS RX HW offload support")
Link: https://lore.kernel.org/netdev/20260627210635.89769-1- 
nils.juenemann@gmail.com/
Reported-by: Nils Juenemann <redacted>
Tested-by: Nils Juenemann <redacted>
Signed-off-by: Rishikesh Jethwani <redacted>
---

Thanks for your patch.

quoted

  .../ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c  | 13 ++++++++++---
  1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ 

ktls_rx.c b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
index bca45679e201..232e998a8f24 100644

--- a/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c
+++ b/drivers/net/ethernet/mellanox/mlx5/core/en_accel/ktls_rx.c

@@ -620,12 +620,15 @@ void mlx5e_ktls_handle_ctx_completion(struct 

mlx5e_icosq_wqe_info *wi)
      queue_work(rule->priv->tls->rx_wq, &rule->work);
  }
-static int mlx5e_ktls_sk_get_rxq(struct sock *sk)
+static int mlx5e_ktls_sk_get_rxq(struct mlx5e_priv *priv, struct sock 
*sk)
  {
      int rxq = sk_rx_queue_get(sk);
      if (unlikely(rxq == -1))
-        rxq = 0;
+        return 0;
+
+    if (unlikely(rxq >= priv->channels.num))
+        return -EINVAL;
      return rxq;
  }

@@ -673,7 +676,11 @@ int mlx5e_ktls_add_rx(struct net_device *netdev, 

struct sock *sk,
      INIT_LIST_HEAD(&priv_rx->list);
      spin_lock_init(&priv_rx->lock);
-    rxq = mlx5e_ktls_sk_get_rxq(sk);
+    rxq = mlx5e_ktls_sk_get_rxq(priv, sk);
+    if (unlikely(rxq < 0)) {
+        err = rxq;
+        goto err_create_tir;
+    }

This is not bullet proof.
Here you just shorten the interval and reduce the probability of the bug.

As this flow is not protected by the state_lock, it is still possible to 
have the num of channels changing after your read above.

IMO, this can't be resolved without holding the mutex here.
I'm doing further research to come up with the proper solution.

Please note we were not CCed on this email.
Let's make sure we're not missed on future ones.