netdev - Re: [PATCH net-next 1/2] xsk: avoid using heavy lock when the pool is not shared

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aQI3TfFZPPaWQOS/@boxer>
Date: Wed, 29 Oct 2025 16:48:29 +0100
From: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To: Jason Xing <kerneljasonxing@...il.com>
CC: <davem@...emloft.net>, <edumazet@...gle.com>, <kuba@...nel.org>,
	<pabeni@...hat.com>, <bjorn@...nel.org>, <magnus.karlsson@...el.com>,
	<jonathan.lemon@...il.com>, <sdf@...ichev.me>, <ast@...nel.org>,
	<daniel@...earbox.net>, <hawk@...nel.org>, <john.fastabend@...il.com>,
	<horms@...nel.org>, <andrew+netdev@...n.ch>, <bpf@...r.kernel.org>,
	<netdev@...r.kernel.org>, Jason Xing <kernelxing@...cent.com>
Subject: Re: [PATCH net-next 1/2] xsk: avoid using heavy lock when the pool
 is not shared

On Sat, Oct 25, 2025 at 02:53:09PM +0800, Jason Xing wrote:
> From: Jason Xing <kernelxing@...cent.com>
> 
> The commit f09ced4053bc ("xsk: Fix race in SKB mode transmit with
> shared cq") uses a heavy lock (spin_lock_irqsave) for the shared
> pool scenario which is that multiple sockets share the same pool.
> 
> It does harm to the case where the pool is only owned by one xsk.
> The patch distinguishes those two cases through checking if the xsk
> list only has one xsk. If so, that means the pool is exclusive and
> we don't need to hold the lock and disable IRQ at all. The benefit
> of this is to avoid those two operations being executed extremely
> frequently.

Even with a single CQ producer we need to have related code within
critical section. One core can be in process context via sendmsg() and
for some reason xmit failed and driver consumed skb (destructor called).

Other core can be at same time calling the destructor on different skb
that has been successfully xmitted, doing the Tx completion via driver's
NAPI. This means that without locking the SPSC concept would be violated.

So I'm afraid I have to nack this.

> 
> With this patch, the performance number[1] could go from 1,872,565 pps
> to 2,147,803 pps. It's a noticeable rise of around 14.6%.
> 
> [1]: taskset -c 1 ./xdpsock -i enp2s0f1 -q 0 -t -S -s 64
> 
> Signed-off-by: Jason Xing <kernelxing@...cent.com>
> ---
>  net/xdp/xsk.c | 14 ++++++++++----
>  1 file changed, 10 insertions(+), 4 deletions(-)
> 
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 7b0c68a70888..76f797fcc49c 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -548,12 +548,15 @@ static int xsk_wakeup(struct xdp_sock *xs, u8 flags)
>  
>  static int xsk_cq_reserve_locked(struct xsk_buff_pool *pool)
>  {
> +	bool lock = !list_is_singular(&pool->xsk_tx_list);
>  	unsigned long flags;
>  	int ret;
>  
> -	spin_lock_irqsave(&pool->cq_lock, flags);
> +	if (lock)
> +		spin_lock_irqsave(&pool->cq_lock, flags);
>  	ret = xskq_prod_reserve(pool->cq);
> -	spin_unlock_irqrestore(&pool->cq_lock, flags);
> +	if (lock)
> +		spin_unlock_irqrestore(&pool->cq_lock, flags);
>  
>  	return ret;
>  }
> @@ -588,11 +591,14 @@ static void xsk_cq_submit_addr_locked(struct xsk_buff_pool *pool,
>  
>  static void xsk_cq_cancel_locked(struct xsk_buff_pool *pool, u32 n)
>  {
> +	bool lock = !list_is_singular(&pool->xsk_tx_list);
>  	unsigned long flags;
>  
> -	spin_lock_irqsave(&pool->cq_lock, flags);
> +	if (lock)
> +		spin_lock_irqsave(&pool->cq_lock, flags);
>  	xskq_prod_cancel_n(pool->cq, n);
> -	spin_unlock_irqrestore(&pool->cq_lock, flags);
> +	if (lock)
> +		spin_unlock_irqrestore(&pool->cq_lock, flags);
>  }
>  
>  static void xsk_inc_num_desc(struct sk_buff *skb)
> -- 
> 2.41.3
>