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

[Tariq Toukan <tariqt@nvidia.com>]

On 15/07/2026 1:29, Rishikesh Jethwani wrote:
> 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 <nils.juenemann@gmail.com>
> Tested-by: Nils Juenemann <nils.juenemann@gmail.com>
> Signed-off-by: Rishikesh Jethwani <rjethwani@purestorage.com>
> ---

Thanks for your patch.

>   .../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.

>   	priv_rx->rxq = rxq;
>   	priv_rx->sk = sk;
>