All of lore.kernel.org
 help / color / mirror / Atom feed
From: Fan Du <fan.du@windriver.com>
To: David Miller <davem@davemloft.net>
Cc: <nicolas.dichtel@6wind.com>, <netdev@vger.kernel.org>
Subject: Re: [DISCUSSION] rt6i_genid
Date: Fri, 19 Jul 2013 11:28:51 +0800	[thread overview]
Message-ID: <51E8B273.1090002@windriver.com> (raw)
In-Reply-To: <20130718.201801.1591610112107900505.davem@davemloft.net>



On 2013年07月19日 11:18, David Miller wrote:
> From: Fan Du<fan.du@windriver.com>
> Date: Fri, 19 Jul 2013 08:01:47 +0800
>
>>
>>
>> On 2013年07月18日 23:12, Nicolas Dichtel wrote:
>>> Le 18/07/2013 11:28, Fan Du a écrit :
>>>>
>>>> Thanks for replying :)
>>>>
>>>> On 2013年07月18日 17:13, Nicolas Dichtel wrote:
>>>>> Le 18/07/2013 05:22, Fan Du a écrit :
>>>>>> Hello Nicolas
>>>>>>
>>>>>> Commit 6f3118b571b8a4c06c7985dc3172c3526cb86253: "ipv6: use
>>>>>> net->rt_genid to
>>>>>> check dst validity"
>>>>>> makes ip6_dst_check to check rt6i_genid against with struct
>>>>>> net->rt_genid,
>>>>>> As a matter of fact, struct net->rt_genid could only be modified by
>>>>>> two places,
>>>>>> first is adding/delete IPv4 address, second is inserting new XFRM
>>>>>> policy.
>>>>>>
>>>>>> Is there any other considerations that adding/deleting IPv4 address
>>>>>> would
>>>>>> invalid all IPv6 dst
>>>>>> as well? because I'm working a patch which actually depends on the
>>>>>> result of
>>>>>> this question.
>>>>> No, the goal was to cover the IPsec case, ie invalidate dst entries
>>>>> when an
>>>>> xfrm policy is inserted/deleted.
>>>>
>>>> Ok, then how about we only checking rt6i_genid against rt_genid *only*
>>>> when XFRM is enabled for IPv6, because when XFRM is not enabled for
>>>> IPv6
>>>> ip6_dst_check for rt_genid is really not necessary.
>>>>
>>>> So what do you think of below modifications?
>>> Seems good. Just a small comment below.
>>
>> Will send v2 for your reviewing when net-next is reopen.
>
> Although it's a correct change, it is of almost no value.  %99.9999999
> of users will be running kernels with CONFIG_XFRM enabled.

Thanks. Good to know %99.99999999 users protect their networking with IPsec.

> So your savings are essentially for no-one.

-- 
浮沉随浪只记今朝笑

--fan

  reply	other threads:[~2013-07-19  3:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-18  3:22 [DISCUSSION] rt6i_genid Fan Du
2013-07-18  9:13 ` Nicolas Dichtel
2013-07-18  9:28   ` Fan Du
2013-07-18 15:12     ` Nicolas Dichtel
2013-07-19  0:01       ` Fan Du
2013-07-19  3:18         ` David Miller
2013-07-19  3:28           ` Fan Du [this message]
2013-07-19  3:31             ` David Miller
2013-07-19  7:50               ` Fan Du
2013-07-19  9:33                 ` David Miller
2013-07-22  5:43                   ` [RFC PATCH net-next] net: split rt_genid for ipv4 and ipv6 Fan Du
2013-07-22 10:53                     ` Steffen Klassert
2013-07-22 20:40                     ` Nicolas Dichtel

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=51E8B273.1090002@windriver.com \
    --to=fan.du@windriver.com \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    /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.