netdev - Re: [Intel-wired-lan] [PATCH net-next 00/10] Call skb_metadata

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: <877btlwur5.fsf@cloudflare.com>
Date: Tue, 13 Jan 2026 13:40:46 +0100
From: Jakub Sitnicki <jakub@...udflare.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Jakub Kicinski <kuba@...nel.org>,  netdev@...r.kernel.org,  "David S.
 Miller" <davem@...emloft.net>,  Eric Dumazet <edumazet@...gle.com>,  Simon
 Horman <horms@...nel.org>,  Michael Chan <michael.chan@...adcom.com>,
  Pavan Chebbi <pavan.chebbi@...adcom.com>,  Andrew Lunn
 <andrew+netdev@...n.ch>,  Tony Nguyen <anthony.l.nguyen@...el.com>,
  Przemek Kitszel <przemyslaw.kitszel@...el.com>,  Saeed Mahameed
 <saeedm@...dia.com>,  Leon Romanovsky <leon@...nel.org>,  Tariq Toukan
 <tariqt@...dia.com>,  Mark Bloch <mbloch@...dia.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>,
  intel-wired-lan@...ts.osuosl.org,  bpf@...r.kernel.org,
  kernel-team@...udflare.com
Subject: Re: [Intel-wired-lan] [PATCH net-next 00/10] Call skb_metadata_set
 when skb->data points past metadata

On Tue, Jan 13, 2026 at 01:09 PM +01, Paolo Abeni wrote:
> IIRC, at early MPTCP impl time, Eric suggested increasing struct sk_buff
> size as an alternative to the mptcp skb extension, leaving the added
> trailing part uninitialized when the sk_buff is allocated.
>
> If skb extensions usage become so ubicuos they are basically allocated
> for each packet, the total skb extension is kept under strict control
> and remains reasonable (assuming it is :), perhaps we could consider
> revisiting the above mentioned approach?

I've been thinking the same thing. Great to hear that this idea is not
new.

FWIW, in our use cases we'd want to attach metadata to the first packet
of new TCP/QUIC flow, and ocassionally to sampled skbs for tracing.