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] [day] [month] [year] [list]

Message-ID: <20251029161218.15aef43e@kernel.org>
Date: Wed, 29 Oct 2025 16:12:18 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
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 Wed, 29 Oct 2025 12:26:50 +0100 Maciej Fijalkowski wrote:
> > 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.

Right.

I guess what I'm saying is that right now we have 4 callers:
 - XDP generic
 - veth
 - devmap 
 - cpumap
these all go thru skb_pp_cow_data() if skb has frags.

You're right that in theory someone can call this function
on a private skb they just constructed (IOW they know they 
don't need to CoW). But IIUC (1) such caller doesn't exist
today; (2) why wouldn't that caller run XDP before allocating
the skb..

So my thinking was to keep this simple for now, used fixed
MEM_TYPE_PAGE_POOL. Add that DEBUG_WARN() and in the kdoc
say that we expect the skbs to have gone thru skb_pp_cow_data().

Worry about conditionals when the odd new user appears.