netdev - Re: [BUG] mlx5_core memory management issue

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: <9b27d605-9211-43c9-aa49-62bbf87f7574@cloudflare.com>
Date: Tue, 12 Aug 2025 11:55:39 -0700
From: Jesse Brandeburg <jbrandeburg@...udflare.com>
To: Dragos Tatulea <dtatulea@...dia.com>, Chris Arges <carges@...udflare.com>
Cc: netdev@...r.kernel.org, bpf@...r.kernel.org,
 kernel-team <kernel-team@...udflare.com>,
 Jesper Dangaard Brouer <hawk@...nel.org>, tariqt@...dia.com,
 saeedm@...dia.com, Leon Romanovsky <leon@...nel.org>,
 Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>,
 John Fastabend <john.fastabend@...il.com>, Simon Horman <horms@...nel.org>,
 Andrew Rzeznik <arzeznik@...udflare.com>, Yan Zhai <yan@...udflare.com>,
 hawk@...nel.org
Subject: Re: [BUG] mlx5_core memory management issue

On 8/12/25 8:44 AM, 'Dragos Tatulea' via kernel-team wrote:

> diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
> index 482d284a1553..484216c7454d 100644
> --- a/kernel/bpf/devmap.c
> +++ b/kernel/bpf/devmap.c
> @@ -408,8 +408,10 @@ static void bq_xmit_all(struct xdp_dev_bulk_queue *bq, u32 flags)
>          /* If not all frames have been transmitted, it is our
>           * responsibility to free them
>           */
> +       xdp_set_return_frame_no_direct();
>          for (i = sent; unlikely(i < to_send); i++)
>                  xdp_return_frame_rx_napi(bq->q[i]);
> +       xdp_clear_return_frame_no_direct();

Why can't this instead just be xdp_return_frame(bq->q[i]); with no 
"no_direct" fussing?

Wouldn't this be the safest way for this function to call frame 
completion? It seems like presuming the calling context is napi is wrong?

The other option here seems to be using the xdp_return_frame_bulk() but 
you'd need to be careful to make sure the rcu lock was taken or already 
held, but it should already be, since it's taken inside xdp_do_flush.

>   
>   out:
>          bq->count = 0;