netdev - Re: [PATCH] ipv6: remove the unnecessary statement in find

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20131031.002234.45924350853188128.davem@davemloft.net>
Date:	Thu, 31 Oct 2013 00:22:34 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	hannes@...essinduktion.org
Cc:	duanj.fnst@...fujitsu.com, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: remove the unnecessary statement in find_match()

From: Hannes Frederic Sowa <hannes@...essinduktion.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@...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@...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?

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html