[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20111012.170218.279202034199478303.davem@davemloft.net>
Date: Wed, 12 Oct 2011 17:02:18 -0400 (EDT)
From: David Miller <davem@...emloft.net>
To: steffen.klassert@...unet.com
Cc: netdev@...r.kernel.org
Subject: Re: [PATCH 1/4] ipv4: Fix pmtu propagating
From: Steffen Klassert <steffen.klassert@...unet.com>
Date: Tue, 11 Oct 2011 13:09:22 +0200
> Since commit 2c8cec5c (ipv4: Cache learned PMTU information in inetpeer)
> we cache the learned pmtu informations in inetpeer and propagate these
> informations with the dst_ops->check() functions. However, these functions
> might not be called for udp and raw packets. As a consequence, we don't
> use the learned pmtu informations in these cases. With this patch we
> call dst_check() from ip_setup_cork() to propagate the pmtu informations.
>
> Signed-off-by: Steffen Klassert <steffen.klassert@...unet.com>
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.
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.
So I cannot see a case where your new check can be necessary.
--
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
Powered by blists - more mailing lists