Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.
From: Wolfgang Walter <hidden>
Date: 2014-12-12 16:58:34
Subsystem:
networking [general], networking [sockets], the rest · Maintainers:
"David S. Miller", Eric Dumazet, Jakub Kicinski, Paolo Abeni, Kuniyuki Iwashima, Willem de Bruijn, Linus Torvalds
Hello Eric, my plan to use e114a710aa5058c0ba4aa1dfb105132aefeb5e04 to make it easier to apply tcp-refine-TSO-autosizing was a bad idea as that needs further patches :-). Backporting tcp-refine-TSO-autosizing https://patchwork.ozlabs.org/patch/418506/ seems to be the easier solution. I tested if 3.18 and 3.17.6 are affected and they are. I applied tcp-refine-TSO-autosizing and the one-liner below and then both work fine. Attached is 1) my backport of tcp-refine-TSO-autosizing for 3.14.26 2) my backport of tcp-refine-TSO-autosizing for 3.17.6 For 3.18 tcp-refine-TSO-autosizing just applies fine. I tested 3.16.26 + patches, 3.17.6 + patches and 3.18.2 + patches. And here again the one-liner: ==================== Subject: tcp: ensure that sk_gso_max_segs = 1 if GSO is disabled sk_setup_caps() may disable GSO even if the network device supports it. This may happens after the creation time of the socket (e.g. triggered by xfrm, PMTU or routing changes). This fixes hangs of local tcp connections over ipsec tunnels where pmtu is lower than the mtu of the interface. --- net/core/sock.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/net/core/sock.c b/net/core/sock.c
--- a/net/core/sock.c
+++ b/net/core/sock.c@@ -1559,6 +1559,7 @@ void sk_setup_caps(struct sock *sk, struct dst_entry *dst) if (sk->sk_route_caps & NETIF_F_GSO) sk->sk_route_caps |= NETIF_F_GSO_SOFTWARE; sk->sk_route_caps &= ~sk->sk_route_nocaps; + sk->sk_gso_max_segs = 1; if (sk_can_gso(sk)) { if (dst->header_len) { sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
--
1.7.10.4
=======================
Do you think the backports are ok? Then Thomas my test them, too.
What should be done now?
First the one line should go into 3.19 as soon as tcp-refine-TSO-autosizing
arrived there?
If both are in Torvald's who should I ask for inclusion into stable?
Am Mittwoch, 10. Dezember 2014, 11:10:03 schrieb Eric Dumazet:
> On Wed, 2014-12-10 at 19:34 +0100, Wolfgang Walter wrote:
> > So gso is on. When the hang happens sk_setup_caps is called from
> > inet_sk_rebuild_header(). Now the path
> >
> > sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
> >
> > is taken as dst->header_len is now non zero.
> >
> > This is the reason why later calls of sk_can_gso() return false.
> >
> > I'll try to change the above patch to
> >
> > @@ -1585,6 +1585,8 @@ void sk_setup_caps(struct sock *sk, struct dst_entry
> > *dst) sk->sk_gso_max_size = dst->dev->gso_max_size;
> >
> > sk->sk_gso_max_segs = dst->dev->gso_max_segs;
> >
> > }
> >
> > }
> >
> > + if (sk_can_gso(sk)) {
> > + sk->sk_gso_max_segs = 1;
> >
> > }
> >
> > }
> > EXPORT_SYMBOL_GPL(sk_setup_caps);
> >
> > so that the case that GSO is disabled because of dst->header_len != 0 sets
> > sk_gso_max_segs, too.
>
> Sounds good, or maybe simply :
>
> diff --git a/net/core/sock.c b/net/core/sock.c
> index
> 9a56b2000c3f374fb95aedada3327447816a9512..edca31319dfee57cabe5b376505324bea
> 07f767a 100644 --- a/net/core/sock.c
> +++ b/net/core/sock.c
> @@ -1577,6 +1577,7 @@ void sk_setup_caps(struct sock *sk, struct dst_entry
> *dst) if (sk->sk_route_caps & NETIF_F_GSO)
> sk->sk_route_caps |= NETIF_F_GSO_SOFTWARE;
> sk->sk_route_caps &= ~sk->sk_route_nocaps;
> + sk->sk_gso_max_segs = 1;
> if (sk_can_gso(sk)) {
> if (dst->header_len) {
> sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
Regards and thank you very much for your help,
--
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen RechtsAttachments
- 0002-tcp-refine-TSO-autosizing.patch [text/x-patch] 7394 bytes · preview
- 0001-tcp-refine-TSO-autosizing.patch [text/x-patch] 6898 bytes · preview