netdev - Re: [PATCH net-next v4 00/12] BIG TCP without HBH in IPv6

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: <CAD0BsJUgkSnbEByqYQdskxp+6riBy4j2Nznr+J6LU4njNiAcbg@mail.gmail.com>
Date: Tue, 3 Feb 2026 13:48:18 +0200
From: Alice Mikityanska <alice@...valent.com>
To: Paolo Abeni <pabeni@...hat.com>
Cc: Alice Mikityanska <alice.projects@...tmail.im>, Daniel Borkmann <daniel@...earbox.net>, 
	"David S. Miller" <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, 
	Jakub Kicinski <kuba@...nel.org>, Xin Long <lucien.xin@...il.com>, 
	Willem de Bruijn <willemdebruijn.kernel@...il.com>, David Ahern <dsahern@...nel.org>, 
	Nikolay Aleksandrov <razor@...ckwall.org>, Shuah Khan <shuah@...nel.org>, 
	Stanislav Fomichev <stfomichev@...il.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v4 00/12] BIG TCP without HBH in IPv6

On Tue, 3 Feb 2026 at 11:51, Paolo Abeni <pabeni@...hat.com> wrote:
>
> On 2/3/26 9:59 AM, Alice Mikityanska wrote:
> > From: Alice Mikityanska <alice@...valent.com>
> >
> > Resubmitting to add one more patch for bng_en. No other changes in code.
> >
> > This series is part 1 of "BIG TCP for UDP tunnels". Due to the number of
> > patches, I'm splitting it into two logical parts:
> >
> > * Remove hop-by-hop header for BIG TCP IPv6 to align with BIG TCP IPv4.
> > * Fix up things that prevent BIG TCP from working with UDP tunnels.
> >
> > The current BIG TCP IPv6 code inserts a hop-by-hop extension header with
> > 32-bit length of the packet. When the packet is encapsulated, and either
> > the outer or the inner protocol is IPv6, or both are IPv6, there will be
> > 1 or 2 HBH headers that need to be dealt with. The issues that arise:
> >
> > 1. The drivers don't strip it, and they'd all need to know the structure
> > of each tunnel protocol in order to strip it correctly, also taking into
> > account all combinations of IPv4/IPv6 inner/outer protocols.
> >
> > 2. Even if (1) is implemented, it would be an additional performance
> > penalty per aggregated packet.
> >
> > 3. The skb_gso_validate_network_len check is skipped in
> > ip6_finish_output_gso when IP6SKB_FAKEJUMBO is set, but it seems that it
> > would make sense to do the actual validation, just taking into account
> > the length of the HBH header. When the support for tunnels is added, it
> > becomes trickier, because there may be one or two HBH headers, depending
> > on whether it's IPv6 in IPv6 or not.
> >
> > At the same time, having an HBH header to store the 32-bit length is not
> > strictly necessary, as BIG TCP IPv4 doesn't do anything like this and
> > just restores the length from skb->len. The same thing can be done for
> > BIG TCP IPv6. Removing HBH from BIG TCP would allow to simplify the
> > implementation significantly, and align it with BIG TCP IPv4, which has
> > been a long-standing goal.
> >
> > v1: https://lore.kernel.org/netdev/20250923134742.1399800-1-maxtram95@gmail.com/
> >
> > v2: https://lore.kernel.org/netdev/20260113212655.116122-1-alice.kernel@fastmail.im/
> >
> > v2 changes:
> >
> > Split the series into two parts. Address the review comments in part 2
> > (details follow with part 2).
> >
> > v3: https://lore.kernel.org/netdev/20260202192338.2373930-1-alice.projects@fastmail.im/
> >
> > v3 changes:
> >
> > No code changes. Added Paolo's ACK. Tcpdump patches have been merged and
> > unblocked the series:
> >
> > https://github.com/the-tcpdump-group/tcpdump/pull/1329
> >
> > v4 changes:
> >
> > Added one more patch for bng_en, because it started using
> > ipv6_hopopt_jumbo_remove in the meanwhile. Added Eric's Reviewed-by.
>
> It's a pity you resubmitted before the 24h grace period

I'm so sorry for this! I was unaware about the grace period, unfortunately.

> without any request to do so.

I received a build error email from kernel test robot, and realized
that another usage of ipv6_hopopt_jumbo_remove was added between v2
and v3. Trust me, I had best intentions: I didn't want my series to
break bng_en in net-next, in case this new usage goes unnoticed before
the series is merged.

> That usually causes a request to wait for 1w before
> the next revision.
>
> Moreover the current one does not apply cleanly to net-next.

My fault! I tried to close the gap ASAP and didn't fetch the changes
that were merged this morning.

> Still I think it would be for the better to be able to include this
> series in the upcoming the merge window, and I guess I'm not alone with
> such hope.
>
> So please wait at least 48h (be accurate about the time) before the next
> revision.
>
> Thanks,
>
> Paolo
>
> p.s. this is my (very lenient) take, other maintainers could ask for a
> different/longer pause.

Thank you, and please forgive my unawareness.