[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <7e99edd2-f725-4226-b686-9efbd9adc2e1@gmail.com>
Date: Wed, 14 Jan 2026 16:52:30 +0100
From: Mariusz Klimek <maklimek97@...il.com>
To: Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org
Subject: Re: [PATCH net-next v2 1/3] net: gso: do not include jumbogram HBH
header in seglen calculation
On 1/13/26 15:14, Paolo Abeni wrote:
> On 1/6/26 10:52 AM, Mariusz Klimek wrote:
>> @@ -177,8 +178,13 @@ static unsigned int skb_gso_transport_seglen(const struct sk_buff *skb)
>> */
>> static unsigned int skb_gso_network_seglen(const struct sk_buff *skb)
>> {
>> - unsigned int hdr_len = skb_transport_header(skb) -
>> - skb_network_header(skb);
>> + unsigned int off = skb_network_offset(skb) + sizeof(struct ipv6hdr);
>> + unsigned int hdr_len = skb_network_header_len(skb);
>> +
>> + /* Jumbogram HBH header is removed upon segmentation. */
>> + if (skb_protocol(skb, true) == htons(ETH_P_IPV6) &&
>> + skb->len - off > IPV6_MAXPLEN)
>> + hdr_len -= sizeof(struct hop_jumbo_hdr);
>
> I'm sorry for splitting the feedback in multiple replies.
>
> I think the concern I expressed on v1:
>
> https://lore.kernel.org/netdev/a7b90a3a-79ed-42a4-a782-17cde1b9a2d6@redhat.com/
>
> is still not addressed here. What I fear is:
>
> - TCP cooks a plain GSO packet just below the 64K limit.
> - Such packet goes trough UDP (or gre) encapsulation, the skb->len size
> (including outer network header) grows above the 64K limit.
> - the above check is satisfied, but no jumbo hop option is present.
>
Could you maybe clarify what you mean?
This check is for the outer IPv6 header. skb->len - off is the IPv6 payload
length so the packet contains a hop-by-hop header if and only if
skb->len - off > IPV6_MAXPLEN. It doesn't matter what comes after the IPv6
header. If the TCP payload is smaller than 65535 and it is the encapsulation
headers that cause the IPv6 payload length to be above 65535, a jumbogram
hop-by-hop header is still added (in ip6_xmit).
> I think you could use the `ipv6_has_hopopt_jumbo()` helper to be on the
> safe side.
Sure, I could submit another revision with this change if my explanation is
unsatisfactory.
>
> /P
>
--
Mariusz K.
Powered by blists - more mailing lists