public inbox for netdev@vger.kernel.org 
 help / color / mirror / Atom feed
From: Steffen Klassert <steffen.klassert@secunet•com>
To: David Miller <davem@davemloft•net>
Cc: netdev@vger•kernel.org
Subject: Re: [PATCH 1/4] ipv4: Fix pmtu propagating
Date: Thu, 13 Oct 2011 12:09:50 +0200	[thread overview]
Message-ID: <20111013100950.GO1830@secunet.com> (raw)
In-Reply-To: <20111012.170218.279202034199478303.davem@davemloft.net>

On Wed, Oct 12, 2011 at 05:02:18PM -0400, David Miller wrote:
> 
> This dst_check() call will only do something if dst->obsolete is non-zero.
> 
> If dst->obsolete can be set in these circumstances, that's a bug.  The
> caller is responsible for providing either a freshly looked up route
> or a cached route which has had dst_check() or sk_dst_check() invoked
> upon it.

dst->obsolete was -1 in all cases I observed, regardless if connected or not.

> 
> I am pretty sure these rules are followed by the current code.
> 
> Again, there are only two scenerios:
> 
> 1) 'rt' is just looked up by caller (f.e. udp_sendmsg() in rt == NULL case),
>    here dst->obsolete is very unlikely to be non-zero.
> 
> 2) Connected case, and we use cached route from the socket, but here
>    we'll use sk_dst_check() to validate the route.  sk_dst_check()
>    makes the necessary dst->ops->check() call if dst->obsolete is
>    non-zero, and in fact that is it's one and only job.
> 

At least it seems that raw_sendmsg() and ping_sendmsg() don't use
a cached route, they do the route lookup in any case. I don't see
where we check if we learned a new pmtu in this cases. 

I added some debugging output and saw that peer->pmtu_learned
has the correct pmtu value, but it never ends up in the metric
of the dst_entry.

With a ping -s 1400 to a destination where the pmtu is 1000
I get for each packet 'Frag needed and DF set (mtu = 1000)'.
That's how I noticed that something changed.

With the dst_check() in ip_setup_cork() I get
'Frag needed and DF set (mtu = 1000)' for the first packet and
all further packets reach the destination, as it was before
commmit 2c8cec5c.

  reply	other threads:[~2011-10-13 10:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-11 11:08 [PATCH net 0/4] ipv4: various pmtu discovery fixes Steffen Klassert
2011-10-11 11:09 ` [PATCH 1/4] ipv4: Fix pmtu propagating Steffen Klassert
2011-10-12 21:02   ` David Miller
2011-10-13 10:09     ` Steffen Klassert [this message]
2011-10-13 17:58       ` David Miller
2011-10-14  5:54         ` Steffen Klassert
2011-10-17 12:18           ` Steffen Klassert
2011-10-19  9:07             ` Gao feng
2011-10-19 19:32               ` David Miller
2011-11-08 19:19                 ` David Miller
2011-11-08 19:33                   ` David Miller
2011-11-09 12:08                     ` Steffen Klassert
2011-11-21  7:56                       ` Steffen Klassert
2011-12-01 18:40                         ` David Miller
2011-10-11 11:10 ` [PATCH 2/4] ipv4: Update pmtu informations on inetpeer only for output routes Steffen Klassert
2011-10-12 21:08   ` David Miller
2011-10-14  6:34     ` Steffen Klassert
2011-11-08 19:36     ` David Miller
2011-11-09 12:11       ` Steffen Klassert
2011-11-14 10:12       ` Steffen Klassert
2011-11-14 19:33         ` David Miller
2011-11-15 10:00           ` Steffen Klassert
2011-11-22 13:20           ` Steffen Klassert
2011-10-11 11:11 ` [PATCH 3/4] ipv4: Fix inetpeer expiration handling Steffen Klassert
2011-10-20  6:24   ` Gao feng
2011-11-08 19:38     ` David Miller
2011-11-09 12:47     ` Steffen Klassert
2011-10-11 11:12 ` [PATCH 4/4] ipv4: Fix inetpeer expire time information Steffen Klassert
2011-10-11 19:54 ` [PATCH net 0/4] ipv4: various pmtu discovery fixes David Miller
2011-11-08 19:41   ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111013100950.GO1830@secunet.com \
    --to=steffen.klassert@secunet$(echo .)com \
    --cc=davem@davemloft$(echo .)net \
    --cc=netdev@vger$(echo .)kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox