* [PATCH] ipv4: properly update pmtu
@ 2012-08-22 6:48 Eric Dumazet
2012-08-22 10:16 ` Sylvain Munaut
2012-08-23 2:15 ` David Miller
0 siblings, 2 replies; 5+ messages in thread
From: Eric Dumazet @ 2012-08-22 6:48 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Julian Anastasov, Sylvain Munaut
From: Eric Dumazet <edumazet@google.com>
Sylvain Munault reported following info :
- TCP connection get "stuck" with data in send queue when doing
"large" transfers ( like typing 'ps ax' on a ssh connection )
- Only happens on path where the PMTU is lower than the MTU of
the interface
- Is not present right after boot, it only appears 10-20min after
boot or so. (and that's inside the _same_ TCP connection, it works
fine at first and then in the same ssh session, it'll get stuck)
- Definitely seems related to fragments somehow since I see a router
sending ICMP message saying fragmentation is needed.
- Exact same setup works fine with kernel 3.5.1
Problem happens when the 10 minutes (ip_rt_mtu_expires) expiration
period is over.
ip_rt_update_pmtu() calls dst_set_expires() to rearm a new expiration,
but dst_set_expires() does nothing because dst.expires is already set.
It seems we want to set the expires field to a new value, regardless
of prior one.
With help from Julian Anastasov.
Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
CC: Julian Anastasov <ja@ssi.bg>
---
net/ipv4/route.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e4ba974..8d6d320 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -956,7 +956,7 @@ static void ip_rt_update_pmtu(struct dst_entry *dst, struct sock *sk,
dst->obsolete = DST_OBSOLETE_KILL;
} else {
rt->rt_pmtu = mtu;
- dst_set_expires(&rt->dst, ip_rt_mtu_expires);
+ rt->dst.expires = max(1UL, jiffies + ip_rt_mtu_expires);
}
}
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] ipv4: properly update pmtu
2012-08-22 6:48 [PATCH] ipv4: properly update pmtu Eric Dumazet
@ 2012-08-22 10:16 ` Sylvain Munaut
2012-08-22 10:21 ` Eric Dumazet
2012-08-23 2:15 ` David Miller
1 sibling, 1 reply; 5+ messages in thread
From: Sylvain Munaut @ 2012-08-22 10:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev, Julian Anastasov
Hi,
> From: Eric Dumazet <edumazet@google.com>
> ip_rt_update_pmtu() calls dst_set_expires() to rearm a new expiration,
> but dst_set_expires() does nothing because dst.expires is already set.
>
> It seems we want to set the expires field to a new value, regardless
> of prior one.
>
> With help from Julian Anastasov.
>
> Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> CC: Julian Anastasov <ja@ssi.bg>
Tested-by: Sylvain Munaut <s.munaut@whatever-company.com>
I confirm this corrects the issue for me. I tested this on 3 machines
with 2 different hw config that all previously exhibited the issue
short after boot and now they've been running with this version of the
patch for hours without problems.
@Eric: Thanks for looking into this.
Cheers,
Sylvain
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ipv4: properly update pmtu
2012-08-22 10:16 ` Sylvain Munaut
@ 2012-08-22 10:21 ` Eric Dumazet
2012-08-22 10:23 ` Eric Dumazet
0 siblings, 1 reply; 5+ messages in thread
From: Eric Dumazet @ 2012-08-22 10:21 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: David Miller, netdev, Julian Anastasov
On Wed, 2012-08-22 at 12:16 +0200, Sylvain Munaut wrote:
> Hi,
>
> > From: Eric Dumazet <edumazet@google.com>
>
> > ip_rt_update_pmtu() calls dst_set_expires() to rearm a new expiration,
> > but dst_set_expires() does nothing because dst.expires is already set.
> >
> > It seems we want to set the expires field to a new value, regardless
> > of prior one.
> >
> > With help from Julian Anastasov.
> >
> > Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > CC: Julian Anastasov <ja@ssi.bg>
>
> Tested-by: Sylvain Munaut <s.munaut@whatever-company.com>
>
> I confirm this corrects the issue for me. I tested this on 3 machines
> with 2 different hw config that all previously exhibited the issue
> short after boot and now they've been running with this version of the
> patch for hours without problems.
>
> @Eric: Thanks for looking into this.
Thans Sylvain for being an early tester of bleeding edge kernel !
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ipv4: properly update pmtu
2012-08-22 10:21 ` Eric Dumazet
@ 2012-08-22 10:23 ` Eric Dumazet
0 siblings, 0 replies; 5+ messages in thread
From: Eric Dumazet @ 2012-08-22 10:23 UTC (permalink / raw)
To: Sylvain Munaut; +Cc: David Miller, netdev, Julian Anastasov
On Wed, 2012-08-22 at 12:21 +0200, Eric Dumazet wrote:
> Thans Sylvain for being an early tester of bleeding edge kernel !
Oh well, I meant to say Thanks ;)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] ipv4: properly update pmtu
2012-08-22 6:48 [PATCH] ipv4: properly update pmtu Eric Dumazet
2012-08-22 10:16 ` Sylvain Munaut
@ 2012-08-23 2:15 ` David Miller
1 sibling, 0 replies; 5+ messages in thread
From: David Miller @ 2012-08-23 2:15 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ja, s.munaut
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 22 Aug 2012 08:48:29 +0200
> From: Eric Dumazet <edumazet@google.com>
>
> Sylvain Munault reported following info :
>
> - TCP connection get "stuck" with data in send queue when doing
> "large" transfers ( like typing 'ps ax' on a ssh connection )
> - Only happens on path where the PMTU is lower than the MTU of
> the interface
> - Is not present right after boot, it only appears 10-20min after
> boot or so. (and that's inside the _same_ TCP connection, it works
> fine at first and then in the same ssh session, it'll get stuck)
> - Definitely seems related to fragments somehow since I see a router
> sending ICMP message saying fragmentation is needed.
> - Exact same setup works fine with kernel 3.5.1
>
> Problem happens when the 10 minutes (ip_rt_mtu_expires) expiration
> period is over.
>
> ip_rt_update_pmtu() calls dst_set_expires() to rearm a new expiration,
> but dst_set_expires() does nothing because dst.expires is already set.
>
> It seems we want to set the expires field to a new value, regardless
> of prior one.
>
> With help from Julian Anastasov.
>
> Reported-by: Sylvain Munaut <s.munaut@whatever-company.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> CC: Julian Anastasov <ja@ssi.bg>
Applied, thanks.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-08-23 2:15 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-08-22 6:48 [PATCH] ipv4: properly update pmtu Eric Dumazet
2012-08-22 10:16 ` Sylvain Munaut
2012-08-22 10:21 ` Eric Dumazet
2012-08-22 10:23 ` Eric Dumazet
2012-08-23 2:15 ` David Miller
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.