netdev - Re: [PATCH bpf 2/2] veth: update mem type in xdp

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: <aOY+4qpQ+tzIWS5Q@boxer>
Date: Wed, 8 Oct 2025 12:37:22 +0200
From: Maciej Fijalkowski <maciej.fijalkowski@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: <bpf@...r.kernel.org>, <ast@...nel.org>, <daniel@...earbox.net>,
	<hawk@...nel.org>, <ilias.apalodimas@...aro.org>, <toke@...hat.com>,
	<lorenzo@...nel.org>, <netdev@...r.kernel.org>, <magnus.karlsson@...el.com>,
	<andrii@...nel.org>, <stfomichev@...il.com>, <aleksander.lobakin@...el.com>
Subject: Re: [PATCH bpf 2/2] veth: update mem type in xdp_buff

On Wed, Oct 08, 2025 at 11:22:26AM +0200, Maciej Fijalkowski wrote:
> On Tue, Oct 07, 2025 at 06:11:53PM -0700, Jakub Kicinski wrote:
> > On Tue, 7 Oct 2025 16:59:21 +0200 Maciej Fijalkowski wrote:
> > > > My thinking was that we should try to bake the rxq into "conversion"
> > > > APIs, draft diff below, very much unfinished and I'm probably missing
> > > > some cases but hopefully gets the point across:  
> > > 
> > > That is not related IMHO. The bugs being fixed have existing rxqs. It's
> > > just the mem type that needs to be correctly set per packet.
> > > 
> > > Plus we do *not* convert frame to buff here which was your initial (on
> > > point) comment WRT onstack rxqs. Traffic comes as skbs from peer's
> > > ndo_start_xmit(). What you're referring to is when source is xdp_frame (in
> > > veth case this is when ndo_xdp_xmit or XDP_TX is used).
> > 
> > I guess we're slipping into a philosophical discussion but I'd say 
> > that the problem is that rxq stores part of what is de facto xdp buff
> > state. It is evacuated into the xdp frame when frame is constructed,
> > as packet is detached from driver context. We need to reconstitute it
> > when we convert frame (skb, or anything else) back info an xdp buff.
> 
> So let us have mem type per xdp_buff then. Feels clunky anyways to change
> it on whole rxq on xdp_buff basis. Maybe then everyone will be happy?

...however would we be fine with taking a potential performance hit?

> 
> > 
> > xdp_convert_buff_to_frame() and xdp_convert_frame_to_buff() should be
> > a mirror image of each other, to put it more concisely.
> > 
> > > However the problem pointed out by AI (!) is something we should fix as
> > > for XDP_{TX,REDIRECT} xdp_rxq_info is overwritten and mem type update is
> > > lost.
> > 
> > > > +/* Initialize an xdp_buff from an skb.
> > > > + *
> > > > + * Note: if skb has frags skb_cow_data_for_xdp() must be called first,
> > > > + * or caller must otherwise guarantee that the frags come from a page pool
> > > > + */
> > > > +static inline
> > > > +void xdp_convert_skb_to_buff(const struct xdp_frame *frame,
> > > > +			     struct xdp_buff *xdp, struct xdp_rxq_info *rxq)  
> > > 
> > > I would expect to get skb as an input here
> > 
> > Joł. Don't nit pick my draft diff :D It's not meant as a working patch.
> 
> Polish sneaked in so this got really under your skin :D
> 
> >