netdev - Re: [PATCH net-next 00/10] Call skb_metadata_set when skb->data points past 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: <87bjixwv41.fsf@cloudflare.com>
Date: Tue, 13 Jan 2026 13:33:02 +0100
From: Jakub Sitnicki <jakub@...udflare.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: netdev@...r.kernel.org,  "David S. Miller" <davem@...emloft.net>,  Eric
 Dumazet <edumazet@...gle.com>,  Paolo Abeni <pabeni@...hat.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: [PATCH net-next 00/10] Call skb_metadata_set when skb->data
 points past metadata

On Mon, Jan 12, 2026 at 07:08 PM -08, Jakub Kicinski wrote:
> On Sat, 10 Jan 2026 22:05:14 +0100 Jakub Sitnicki wrote:
>> This series is split out of [1] following discussion with Jakub.
>> 
>> To copy XDP metadata into an skb extension when skb_metadata_set() is
>> called, we need to locate the metadata contents.
>
> "When skb_metadata_set() is called"? I think that may cause perf
> regressions unless we merge major optimizations at the same time?
> Should we defer touching the drivers until we have a PoC and some
> idea whether allocating the extension right away is manageable or 
> we are better off doing it via a kfunc in TC (after GRO)?
> To be clear putting the metadata in an extension right away would
> indeed be much cleaner, just not sure how much of the perf hit we 
> can optimize away..

Good point. I'm hoping we don't have to allocate from
skb_metadata_set(), which does sound prohibitively expensive. Instead
we'd allocate the extension together with the skb if we know upfront
that metadata will be used.

Things took an unexpected turn and I'm figuring this out as I go.
Please bear with me :-)

Here are my thoughts:

1) The driver changes do clean up the interface, but you're right that
   it's premature churn if the approach changes. If the skb extension
   approach doesn't pan out, we're ready to fall back to headroom-based
   storage.

2) How do we handle CONFIG_SKB_EXTENSIONS=n? Without extensions,
   reliable metadata access after L2 encap/decap would require patching
   skb_push/pull call sites—or we declare the feature unsupported
   without CONFIG_SKB_EXTENSIONS=y.

3) When skb extensions are enabled, asking users to attach TC BPF progs
   to call a kfunc to all devices the skb goes through before L2
   encap/decap is impractical. The extension alloc/move needs to be
   baked into the stack.

I'll focus on getting a PoC together next. Stay tuned.

Thanks,
-jkbs