All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gao feng <gaofeng@cn.fujitsu.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: davem@davemloft.net, kuznet@ms2.inr.ac.ru, jmorris@namei.org,
	netdev@vger.kernel.org
Subject: Re: [PATCH] route:ip_rt_frag_needed always return unzero
Date: Wed, 19 Oct 2011 13:20:28 +0800	[thread overview]
Message-ID: <4E9E5E1C.5020603@cn.fujitsu.com> (raw)
In-Reply-To: <1318996187.19139.8.camel@edumazet-laptop>

于 2011年10月19日 11:49, Eric Dumazet 写道:
> Le mercredi 19 octobre 2011 à 09:34 +0800, Gao feng a écrit :
>> 2011.10.18 17:23, Eric Dumazet wrote:
>>> Le mardi 18 octobre 2011 à 15:04 +0800, Gao feng a écrit :
>>>> int function ip_rt_frag_need,if peer is null,
>>>> there is no need to do ipprot->err_handler.
>>>> I am right?
>>>>
>>>> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com>
>>>> ---
>>>>  net/ipv4/route.c |    2 +-
>>>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/net/ipv4/route.c b/net/ipv4/route.c
>>>> index 075212e..6cde0fa 100644
>>>> --- a/net/ipv4/route.c
>>>> +++ b/net/ipv4/route.c
>>>> @@ -1574,7 +1574,7 @@ unsigned short ip_rt_frag_needed(struct net *net, const struct iphdr *iph,
>>>>  
>>>>  		atomic_inc(&__rt_peer_genid);
>>>>  	}
>>>> -	return est_mtu ? : new_mtu;
>>>> +	return est_mtu;
>>>>  }
>>>>  
>>>>  static void check_peer_pmtu(struct dst_entry *dst, struct inet_peer *peer)
>>>
>>> No idea why you want this, your changelog is a bit cryptic :)
>>>
>>> Wont this bypass the raw_icmp_error(skb, protocol, info);
>>> call in icmp_unreach() as well ?
>>>
>>>
>>
>> thanks Eric!
>>
>> 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?
> 
> 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??

The return value of ip_rt_frag_needed is not very clear.
Eric,can you tell me something?

> 
> Not finding/create inet_peer is very unlikely : This occurs only under
> high stress and out of memory condition. Is it really happening on your
> machines ?
> 
> 

It's not happening on my machines.

thanks.

  reply	other threads:[~2011-10-19  5:20 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-10-18  7:04 [PATCH] route:ip_rt_frag_needed always return unzero Gao feng
2011-10-18  9:23 ` Eric Dumazet
2011-10-19  1:34   ` Gao feng
2011-10-19  2:33     ` Gao feng
2011-10-19  3:57       ` Eric Dumazet
2011-10-19  3:49     ` Eric Dumazet
2011-10-19  5:20       ` Gao feng [this message]
2011-10-19  5:47         ` Eric Dumazet
2011-10-19  6:36           ` Gao feng
2011-10-19  7:26         ` Steffen Klassert
2011-10-19  8:07           ` Gao feng
2011-10-19  8:38             ` Steffen Klassert
2011-10-19  8:59               ` Gao feng

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=4E9E5E1C.5020603@cn.fujitsu.com \
    --to=gaofeng@cn.fujitsu.com \
    --cc=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=jmorris@namei.org \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=netdev@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.