From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
To: David Miller <davem@davemloft.net>
Cc: hannes@stressinduktion.org, netdev@vger.kernel.org
Subject: Re: [PATCH] ipv6: remove the unnecessary statement in find_match()
Date: Thu, 31 Oct 2013 14:02:11 +0800 [thread overview]
Message-ID: <5271F263.4020800@cn.fujitsu.com> (raw)
In-Reply-To: <20131031.002234.45924350853188128.davem@davemloft.net>
于 2013年10月31日 12:22, David Miller 写道:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Wed, 30 Oct 2013 22:11:57 +0100
>
>> On Wed, Oct 30, 2013 at 05:08:37PM -0400, David Miller wrote:
>>> From: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>> Date: Wed, 30 Oct 2013 15:39:26 +0800
>>>
>>>>
>>>> After reading the function rt6_check_neigh(), we can
>>>> know that the RT6_NUD_FAIL_SOFT can be returned only
>>>> when the IS_ENABLE(CONFIG_IPV6_ROUTER_PREF) is false.
>>>> so in function find_match(), there is no need to execute
>>>> the statement !IS_ENABLED(CONFIG_IPV6_ROUTER_PREF).
>>>>
>>>> Signed-off-by: Duan Jiong <duanj.fnst@cn.fujitsu.com>
>>>
>>> Applied to net-next, thanks.
>>>
>>> CONFIG_IPV6_ROUTER_PREF is another good candidate for Kconfig
>>> removal. I know we've had several bugs that only apply when
>>> this option is on vs. off. We're maintaining two different
>>> code paths, for really no good reason.
>>
>> I agree and actually thought about that yesterday. Do you think a sysctl
>> is a good option?
>
> Every distribution ships with the Kconfig option on, and no sysctl
> exists currently to control it.
>
> So I'd say it's not necessary at all, or at the very least let's have
> someone come forward with a real rather than theoretical use case for
> such a feature before adding it.
>
> Actually, if RFC 4191 has the usual language like "there SHOULD be
> an administrative mechanism to disable blah blah blah" I could
> be convinced to add it now. Can someone take a look?
It seems that there is no such an administrative mechanism in RFC 4191.
By the way, if the sysctl is used, we are still maintaining two different
code paths, isn't it? so i think David's idea is good.
Thanks,
Duan
>
> Either way it'd probably be a per-inet6_dev option, right?
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2013-10-31 6:04 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-30 7:39 [PATCH] ipv6: remove the unnecessary statement in find_match() Duan Jiong
2013-10-30 9:44 ` Hannes Frederic Sowa
2013-10-30 21:08 ` David Miller
2013-10-30 21:11 ` Hannes Frederic Sowa
2013-10-31 4:22 ` David Miller
2013-10-31 6:02 ` Duan Jiong [this message]
2013-10-31 8:45 ` Hannes Frederic Sowa
2013-10-31 11:09 ` Duan Jiong
2013-10-31 11:57 ` Hannes Frederic Sowa
2013-11-01 22:08 ` 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=5271F263.4020800@cn.fujitsu.com \
--to=duanj.fnst@cn.fujitsu.com \
--cc=davem@davemloft.net \
--cc=hannes@stressinduktion.org \
--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.