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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 02 May 2013 14:45:36 +0200
From:	Bjørn Mork <bjorn@...k.no>
To:	Cong Wang <amwang@...hat.com>
Cc:	netdev@...r.kernel.org, David Stevens <dlstevens@...ibm.com>,
	Stephen Hemminger <stephen@...workplumber.org>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [Patch net-next v7 4/6] vxlan: add ipv6 support

Cong Wang <amwang@...hat.com> writes:
> On Tue, 2013-04-30 at 12:33 +0200, Bjørn Mork wrote:
>> 
>> Well, you have been told that your proposed new feature breaks IPv4
>> support with specific settings.  I do not think that you are speeding
>> up
>> anything here by ignoring that fact.  On the contrary. 
>
> It is obviously a corner case which is not deserved such a high priority
> (as high as a kernel panic or a compile error). bindv6only is default to
> be 0, I even wasn't aware of such sysctl until David pointed it out.

It's a regression. Regressions trump new features. No need to argue
about the relative importance here.  Fix it.

> So, please give me a reason why we should let such a corner case block
> the inclusion? I think there are still other such corner cases too (and
> maybe many), which neither you nor me are aware of.

Yes, I am pretty sure of that as well.  That's why I ask you to *test*
your code with assorted settings before resubmitting it.  I'm not going
to.

I note that you claim you are not an expert.  Neither am I.  And luckily
I believe that is not required around here. Anyone can contribute, and
all contributions are very welcome.  At least that is the impression
I've got.

But only the experts can get away with limited testing. The less of an
expert you are, the more time you need to spend trying out every small
codepath you added using every possible input combination.  Doing
different combinations of buildtime and runtime IPv6 enable/disable is
an obvious requirement when you add code which has some sort of "if IPv6
is enabled" conditionals.  IMHO.



Bjørn
--
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ