netdev - Re: [bisected] xfrm: TCP connection initiating PMTU discovery stalls on v3.

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <3485487.Ob8lM3Vmqr@h2o.as.studentenwerk.mhn.de>
Date:	Thu, 11 Dec 2014 01:36:48 +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.

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;

Yes, true.


This fixes the issue. That means no hangs any more even if gso is enabled on 
the device serving the ipsec traffic.

As said I could not apply https://patchwork.ozlabs.org/patch/418506/ 
unmodified to 3.14. This is because the following patch is missing in v.3.14:

commit e114a710aa5058c0ba4aa1dfb105132aefeb5e04
Author: Eric Dumazet <edumazet@...gle.com>
Date:   Wed Apr 30 11:58:13 2014 -0700

    tcp: fix cwnd limited checking to improve congestion control

(and the follow-up 249015515fe3fc9818d86cb5c83bbc92505ad7dc).

I'll next try to apply these patches on v3.14.26, see if the other patch then 
applies cleanly, add that one-liner - and hopefully it will work.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html