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]
Message-ID: <m139q6ahld.fsf@fess.ebiederm.org>
Date:	Thu, 09 Dec 2010 11:09:34 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Brian Haley <brian.haley@...com>
Cc:	David Miller <davem@...emloft.net>, netdev@...r.kernel.org,
	Mahesh Kelkar <maheshkelkar@...il.com>,
	Lorenzo Colitti <lorenzo@...gle.com>,
	YOSHIFUJI Hideaki <yoshfuji@...ux-ipv6.org>,
	Stephen Hemminger <shemminger@...tta.com>, stable@...nel.org
Subject: Re: [PATCH] Fix 2.6.34-rc1 regression in  disable_ipv6 support

Brian Haley <brian.haley@...com> writes:

> On 12/08/2010 11:16 PM, Eric W. Biederman wrote:
>> Finding the real bug is beyond me right now, but fixing the regression
>> in disable_ipv6 is simple.  We can just delete ::1 when we bring down
>> the loopback interface, and it will be restored automatically when we
>> bring the loopback interface back up.
>
> Hi Eric,
>
> This would work as well, same check, different way.

But that looks like less of an obvious magic exception.  The only
address it is safe to ignore on is ::1, because we always restore it
when we bring the loopback interface up.

Long term we really do want to keep the loopback address.  But
that actually requires finding and fixing what is broken in
ipv6.

So let's please keep this a line that we can easily remove.  It isn't
like interfaces coming up and down are a fast path where every cycle
counts.  We just need to be reasonably efficient.

Eric
--
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