All of lore.kernel.org
 help / color / mirror / Atom feed
* [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.