netdev - Re: [PATCH] Fix 2.6.34-rc1 regression in disable

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, 9 Dec 2010 14:51:43 -0800
From:	Stephen Hemminger <shemminger@...tta.com>
To:	David Miller <davem@...emloft.net>
Cc:	ebiederm@...ssion.com, brian.haley@...com, netdev@...r.kernel.org,
	maheshkelkar@...il.com, lorenzo@...gle.com,
	yoshfuji@...ux-ipv6.org, stable@...nel.org
Subject: Re: [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support

On Thu, 09 Dec 2010 12:20:33 -0800 (PST)
David Miller <davem@...emloft.net> wrote:

> From: Stephen Hemminger <shemminger@...tta.com>
> Date: Thu, 9 Dec 2010 11:16:11 -0800
> 
> > No but since removing address propagates up to user space daemons
> > like Quagga please analyze and fix the problem, don't just look
> > for band aid.
> 
> Stephen, we lived with the previous behavior for 12+ years.
> 
> You broke stuff that did work before your change.
> 
> Putting the onus on Eric to fix it exactly how you want it to
> be fixed is therefore not appropriate.
> 
> You seem to be putting exactly zero effort into trying to reproduce
> the problem yourself and fixing a bug you introduced.  And hey we
> have a standard way to deal with a regression when the guilty party
> is uncooperative, revert.
> 
> There are therefore three choices:
> 
> 1) Revert.  And this is the one I'm favoring because of how you are
>    handling this issue.  The responsibility to resolve this regression
>    is your's not Eric's.
> 
>    Frankly, Eric is being incredibly nice by working on trying to fix
>    a bug which you introduced.
> 
> 2) Accept Eric's proposed fix.
> 
> 3) Figure out the real bug yourself and fix the problem the way you
>    find acceptable in a reasonable, short, amount of time.
> 
> Loopback has always been special, especially on ipv6.  When we don't
> have a device to point something at, we point it at loopback.
> 
> Also destination cache entries which still have references when they
> get zapped get pointed at loopback.

Quit being a grinch. I am working on it, just don't know the answer.
I want to try a couple solutions, so far Eric's looks okay, just want
to make sure that it doesn't break anything.

You are over reacting. Doing on the fly re-enabling of ipv6 is a corner case.
The problem was only discovered a couple of days ago, it is not like
the world is burning down.


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