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

[Tariq Toukan <tariqt@nvidia.com>]

On 16/07/2026 11:35, Tariq Toukan wrote:
> 
> 
> 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.
> 
Please note we were not CCed on this email.
Let's make sure we're not missed on future ones.