Re: [PATCH net] net/mlx5e: xsk: Fix unlocked writing to ICOSQ

[Simon Horman <horms@kernel.org>]

On Wed, May 13, 2026 at 09:46:13AM +0300, Tariq Toukan wrote:
> From: Dragos Tatulea <dtatulea@nvidia.com>
> 
> During napi poll, when the affinity changes and there's still XSK work
> to be done, we trigger an ICOSQ interrupt on the new CPU. However, this
> triggering on the ICOSQ is done unprotected.
> 
> There are 2 such races:
> 
> A) mlx5e_trigger_irq() is called while mlx5e_xsk_alloc_rx_mpwqe() is
> running from a different CPU due to affinity change. This can happen
> because IRQ triggering is done after napi_complete_done(). At this point
> the NAPI can be scheduled on a different CPU. Like this:
> 
>   CPU A (old affinity, NAPI tail)    CPU B (new affinity, fresh NAPI)
>   -------------------------------    --------------------------------
>   napi_complete_done()  clears SCHED
>   mlx5e_cq_arm(...)
>                                      napi_schedule_prep() sets SCHED
>                                      mlx5e_napi_poll()
>                                        mlx5e_xsk_alloc_rx_mpwqe()
>                                          mlx5e_icosq_sync_lock() // noop
>                                          memcpy 640 B UMR body
>                                          advance sq->pc by 10
>   mlx5e_trigger_irq(&c->icosq)
>     wqe_info[pi] = {NOP, 1}
>     mlx5e_post_nop() advances sq->pc
> 
> B) mlx5e_trigger_irq() is called on the ICOSQ when
> mlx5e_trigger_napi_icosq() is running.
> 
> The obvious fix would be to lock the ICOSQ. But ICOSQ has an optimized
> locking scheme that doesn't work for this scenario. Kick the async ICOSQ
> instead which is always locked.

...

> Fixes: db05815b36cb ("net/mlx5e: Add XSK zero-copy support")
> Reported-by: Paul Saab <ps@mu.org>
> Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
> Signed-off-by: Tariq Toukan <tariqt@nvidia.com>

Reviewed-by: Simon Horman <horms@kernel.org>