Subject: Re: [PATCH] route:ip_rt_frag_needed always return unzero

From: Steffen Klassert <[email-masked]>
Date: Wed, 19 Oct 2011 09:26:29 +0200

On Wed, Oct 19, 2011 at 01:20:28PM +0800, Gao feng wrote:
> 于 2011年10月19日 11:49, Eric Dumazet 写道:
> > Le mercredi 19 octobre 2011 à 09:34 +0800, Gao feng a écrit :
> >>
> >> I mean that the pmtu is update by inet_peer->pmtu_learned as I know.
> >> so in function ip_rt_frag_needed,
> >> if inet_peer is null or someting else make the setting of inet_peer->pmtu_learned failed.
> >> there is no need to call function tcp_v4_err.
> >>
> >> the call stack is
> >> icmp_unreach
> >>   |
> >>   |--->ip_rt_frag_needed(fill inet_peer)
> >>   |
> >>   |--->raw_icmp_error()
> >>   |
> >>   |--->ipprot->err_handler(tcp_v4_err or something else)
> >> 	|
> >> 	|--->tcp_v4_err(frag need icmp is triggered by tcp packet)
> >> 		|
> >> 		|--->do_pmtu_discovery
> >> 		(in this function both __sk_dst_check or dst->ops->update_pmtu
> >> 		need struct inet_peer to update pmtu)
> >>
> >> so,I think when set inet_peer->pmtu_learned failed,
> >> in func icmp_unreach we should goto out immediately.
> >>
> >> And it's confuse me that why func ping_err and udp_err not update the pmtu?
> >> What I miss?

On udp and raw sockets, the user is responsible to adjust the packet
size according to the mtu value he may find in the socket's error queue.
So we shoud provide the user with this information, even in the unlikely
case where we could not create an inet_peer.

> > 
> > You dont answer my question : After your patch, we now dont call
> > raw_icmp_error() anymore. Why is is valid ?
> 
> After my patch
> raw_icmp_error don't call only when setting inet_peer failed(ip_rt_frag_needed return zero).
> And I think it's unexpected,should goto out immediately.
> 
> In orig ip_rt_frag_need,
> zero can be return only when pmtu(get from icmp packet) is zero and peer is NULL.
> in this case,raw_icmp_error will not be call too.this is valid??
> 

It is valid in the sense that we should not provide the user
with a mtu information if we know that the value we got from
the icmp packet ist bogus. But perhaps we can think about
making the check for a valid mtu unconditionally and let
ip_rt_frag_needed return a valid mtu in any case.