netdev - Re: [PATCH v4 bpf 1/2] xdp: introduce xdp_convert_skb_to

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: <aQH5+ojHJ1V9jfk8@boxer>
Date: Wed, 29 Oct 2025 12:26:50 +0100
From: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Jesper Dangaard Brouer <hawk@...nel.org>, <bpf@...r.kernel.org>,
	<ast@...nel.org>, <daniel@...earbox.net>, <netdev@...r.kernel.org>,
	<magnus.karlsson@...el.com>, <aleksander.lobakin@...el.com>,
	<ilias.apalodimas@...aro.org>, <toke@...hat.com>, <lorenzo@...nel.org>,
	<syzbot+ff145014d6b0ce64a173@...kaller.appspotmail.com>, Ihor Solodrai
	<ihor.solodrai@...ux.dev>, Octavian Purdila <tavip@...gle.com>
Subject: Re: [PATCH v4 bpf 1/2] xdp: introduce xdp_convert_skb_to_buff()

On Tue, Oct 28, 2025 at 06:53:14PM -0700, Jakub Kicinski wrote:
> On Tue, 28 Oct 2025 09:08:52 +0100 Jesper Dangaard Brouer wrote:
> > > +	xdp->rxq->mem.type = page_pool_page_is_pp(virt_to_head_page(xdp->data)) ?
> > > +				MEM_TYPE_PAGE_POOL : MEM_TYPE_PAGE_SHARED;  
> > 
> > We are slowly killing performance with these paper cuts.  The
> > information we are looking for should be available via skb->pp_recycle,
> > but instead we go lookup the page to deref that memory.  And plus the
> > virt_to_head_page() is more expensive than virt_to_page().
> > 
> > Why don't we check skb->pp_recycle first, and then fall-back to checking
> > the page to catch the mentioned problems?

Hi Jesper, Jakub,

we started with pp_recycle so if we now have agreement regarding its usage
here let me send another revision. My assumption was that generic XDP was
not that performance-sensitive for us, however this helper is going to be
used within {dev,cpu}map, so I agree with your concerns now.

> 
> I still think _all_ frags which may end up here are from the per CPU PP
> since we CoW the skbs. So:

Agree!

> 
> 	DEBUG_NET_WARN_ON_ONCE(!skb->pp_recycle);
> 	xdp->rxq->mem.type = MEM_TYPE_PAGE_POOL;

This has to be conditional as it is fine to use this helper for
MEM_TYPE_PAGE_SHARED, plus the mem type has to be updated per packet.

> 
> ? It is legal to have pp and non-pp frags in a single skb AFAIK.

Ok, but not in this case where data origins from CoW path.

>