[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CANn89i+uOpwoboVi_K2MSn9x=isakxLaz1+ydTfEfGtK9h4C0g@mail.gmail.com>
Date: Fri, 2 Jun 2023 04:30:25 +0200
From: Eric Dumazet <edumazet@...gle.com>
To: Alexander Duyck <alexanderduyck@...a.com>
Cc: "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
Xin Long <lucien.xin@...il.com>, David Ahern <dsahern@...nel.org>,
"eric.dumazet@...il.com" <eric.dumazet@...il.com>
Subject: Re: [PATCH net] tcp: gso: really support BIG TCP
On Thu, Jun 1, 2023 at 11:46 PM Alexander Duyck <alexanderduyck@...a.com> wrote:
>
>
>
> > -----Original Message-----
> > From: Eric Dumazet <edumazet@...gle.com>
> > Sent: Thursday, June 1, 2023 2:18 PM
> > To: David S . Miller <davem@...emloft.net>; Jakub Kicinski
> > <kuba@...nel.org>; Paolo Abeni <pabeni@...hat.com>
> > Cc: netdev@...r.kernel.org; Xin Long <lucien.xin@...il.com>; David Ahern
> > <dsahern@...nel.org>; eric.dumazet@...il.com; Eric Dumazet
> > <edumazet@...gle.com>; Alexander Duyck <alexanderduyck@...a.com>
> > Subject: [PATCH net] tcp: gso: really support BIG TCP
> >
> > >
> > We missed that tcp_gso_segment() was assuming skb->len was smaller than
> > 65535 :
> >
> > oldlen = (u16)~skb->len;
> >
> > This part came with commit 0718bcc09b35 ("[NET]: Fix CHECKSUM_HW GSO
> > problems.")
> >
> > This leads to wrong TCP checksum.
> >
> > Simply use csum_fold() to support 32bit packet lengthes.
> >
> > oldlen name is a bit misleading, as it is the contribution of skb->len on the
> > input skb TCP checksum. I added a comment to clarify this point.
> >
> > Fixes: 09f3d1a3a52c ("ipv6/gso: remove temporary HBH/jumbo header")
> > Signed-off-by: Eric Dumazet <edumazet@...gle.com>
> > Cc: Alexander Duyck <alexanderduyck@...com>
> > ---
> > net/ipv4/tcp_offload.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/ipv4/tcp_offload.c b/net/ipv4/tcp_offload.c index
> > 45dda788938704c3f762256266d9ea29b6ded4a5..5a1a163b2d859696df8f204b5
> > 0e3fc76c14b64e9 100644
> > --- a/net/ipv4/tcp_offload.c
> > +++ b/net/ipv4/tcp_offload.c
> > @@ -75,7 +75,8 @@ struct sk_buff *tcp_gso_segment(struct sk_buff *skb,
> > if (!pskb_may_pull(skb, thlen))
> > goto out;
> >
> > - oldlen = (u16)~skb->len;
> > + /* Contribution of skb->len in current TCP checksum */
> > + oldlen = (__force u32)csum_fold((__force __wsum)skb->len);
> > __skb_pull(skb, thlen);
> >
> > mss = skb_shinfo(skb)->gso_size;
>
> The only thing I am not sure about with this change is if we risk overflowing a u32 with all the math that may occur. The original code couldn't exceed a u16 for delta since we were essentially adding -oldlen + new header + mss. With us now allowing the use of a value larger than 16 bit we should be able to have the resultant value exceed 16b which means we might overflow when we add it to the current checksum.
>
> As such we may want to look at holding off on the csum_fold until after we have added the new header and mss and then store the folded value in delta.
>
I think you missed that csum_fold() result is also a 16bit value.
Logic Herbert added years ago will work the same.
Here is the pure C implementation of csum_fold(), I hope this will
clear your concerns.
static inline __sum16 csum_fold(__wsum csum)
{
u32 sum = (__force u32)csum;
sum = (sum & 0xffff) + (sum >> 16);
sum = (sum & 0xffff) + (sum >> 16);
return (__force __sum16)~sum;
}
TCP ipv6 stack populates th->check with tcp_v6_send_check()
->
__tcp_v6_send_check(skb, &sk->sk_v6_rcv_saddr, &sk->sk_v6_daddr);
->
th->check = ~tcp_v6_check(skb->len, saddr, daddr, 0);
Thanks !
Powered by blists - more mailing lists