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: <aYms_0wdZQ4AwRc9@soc-5CG4396X81.clients.intel.com>
Date: Mon, 9 Feb 2026 10:46:39 +0100
From: Larysa Zaremba <larysa.zaremba@...el.com>
To: Jakub Kicinski <kuba@...nel.org>
CC: Vladimir Oltean <vladimir.oltean@....com>, <bpf@...r.kernel.org>, "Claudiu
 Manoil" <claudiu.manoil@....com>, Wei Fang <wei.fang@....com>, Clark Wang
	<xiaoning.wang@....com>, Andrew Lunn <andrew+netdev@...n.ch>, "David S.
 Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, "Paolo
 Abeni" <pabeni@...hat.com>, Tony Nguyen <anthony.l.nguyen@...el.com>,
	"Przemek Kitszel" <przemyslaw.kitszel@...el.com>, Alexei Starovoitov
	<ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, Jesper Dangaard
 Brouer <hawk@...nel.org>, John Fastabend <john.fastabend@...il.com>,
	"Stanislav Fomichev" <sdf@...ichev.me>, Andrii Nakryiko <andrii@...nel.org>,
	"Martin KaFai Lau" <martin.lau@...ux.dev>, Eduard Zingerman
	<eddyz87@...il.com>, Song Liu <song@...nel.org>, Yonghong Song
	<yonghong.song@...ux.dev>, KP Singh <kpsingh@...nel.org>, Hao Luo
	<haoluo@...gle.com>, Jiri Olsa <jolsa@...nel.org>, Simon Horman
	<horms@...nel.org>, Shuah Khan <shuah@...nel.org>, Alexander Lobakin
	<aleksander.lobakin@...el.com>, "Maciej Fijalkowski"
	<maciej.fijalkowski@...el.com>, "Bastien Curutchet (eBPF Foundation)"
	<bastien.curutchet@...tlin.com>, Tushar Vyavahare
	<tushar.vyavahare@...el.com>, Jason Xing <kernelxing@...cent.com>, Ricardo
 B. Marlière <rbm@...e.com>, Eelco Chaudron
	<echaudro@...hat.com>, Lorenzo Bianconi <lorenzo@...nel.org>, "Toke
 Hoiland-Jorgensen" <toke@...hat.com>, <imx@...ts.linux.dev>,
	<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
	<intel-wired-lan@...ts.osuosl.org>, <linux-kselftest@...r.kernel.org>,
	Aleksandr Loktionov <aleksandr.loktionov@...el.com>
Subject: Re: [PATCH bpf 6/6] net: enetc: use truesize as XDP RxQ info
 frag_size

On Fri, Feb 06, 2026 at 06:57:35PM -0800, Jakub Kicinski wrote:
> On Fri, 6 Feb 2026 09:36:21 +0100 Larysa Zaremba wrote:
> > > FWIW my feeling is that instead of nickel and diming leftover space 
> > > in the frags if someone actually cared about growing mbufs we should
> > > have the helper allocate a new page from the PP and append it to the
> > > shinfo. Much simpler, "infinite space", and works regardless of the
> > > driver. I don't mean that to suggest you implement it, purely to point
> > > out that I think nobody really uses positive offsets.. So we can as
> > > well switch more complicated drivers back to xdp_rxq_info_reg().
> > 
> > As Vladimir has mentioned, if the driver does not use header split, frags will 
> > have a tailroom of a size of skb_shared_info, so tail growing does work in 
> > practice.
> > 
> > Allocating a page_pool buffer (given XDP queue has one attached) is certainly an 
> > option, although I am not sure if anyone needs it. Furthermore, growing tail 
> > would still fail for a single-buf case.
> 
> sbuf is a different code path, sbuf has precise frame_sz per frame,
> not a single value in rxq, no? Don't mean to argue, just making sure
> my mental model is correct ;)
> 

You are right, xdp_buff in sbuf case is self-sufficient inside of bpf ops. sbuf 
mostly requires memory info from XDP RxQ for proper xdp_frame handling.

What I meant is that intended conditions of failure to grow tail are the same 
for sbuf and mbuf case, the last (which can be the same as the first) buffer 
needs to have enough leftover space.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ