[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2630078.LdJXSsPB40@h2o.as.studentenwerk.mhn.de>
Date: Fri, 12 Dec 2014 17:58:31 +0100
From: Wolfgang Walter <linux@...m.de>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: Thomas Jarosch <thomas.jarosch@...ra2net.com>,
netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Steffen Klassert <steffen.klassert@...unet.com>
Subject: Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.
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 Rechts
View attachment "0002-tcp-refine-TSO-autosizing.patch" of type "text/x-patch" (7394 bytes)
View attachment "0001-tcp-refine-TSO-autosizing.patch" of type "text/x-patch" (6899 bytes)
Powered by blists - more mailing lists