From: Stephen Hemminger <shemminger@vyatta.com>
To: ebiederm@xmission.com (Eric W. Biederman)
Cc: Jiri Bohac <jbohac@suse.cz>, David Miller <davem@davemloft.net>,
brian.haley@hp.com, netdev@vger.kernel.org,
maheshkelkar@gmail.com, lorenzo@google.com,
yoshfuji@linux-ipv6.org, stable@kernel.org
Subject: Re: [RFC] ipv6: don't flush routes when setting loopback down
Date: Sun, 23 Jan 2011 09:39:40 +1100 [thread overview]
Message-ID: <20110123093940.4f6075a3@s6510> (raw)
In-Reply-To: <m1k4hxuzcq.fsf@fess.ebiederm.org>
On Sat, 22 Jan 2011 00:17:09 -0800
ebiederm@xmission.com (Eric W. Biederman) wrote:
> Stephen Hemminger <shemminger@vyatta.com> writes:
>
> > On Wed, 19 Jan 2011 20:56:32 +0100
> > Jiri Bohac <jbohac@suse.cz> wrote:
> >
> >> On Wed, Jan 19, 2011 at 11:38:17AM -0800, Stephen Hemminger wrote:
> >> > Jiri Bohac <jbohac@suse.cz> wrote:
> >> > > I have the feeling that Eric's patch is the safest solution we
> >> > > have so far:
> >> > Eric's patch has other regressions, see the discussion.
> >>
> >> What regression do you mean? I have read the whole discussion
> >> thoroughly. You only say in one message that deleting ::1 would
> >> propagate to routing daemons. And Eric correctly stated that
> >> people couldn't hit this, because deleting ::1 would break
> >> things on its own.
> >>
> >> Is there a real problem with Eric's fix?
> >>
> >> Thanks,
> >>
> >
> > If address is assigned to loopback interface (other than ::1) then
> > Eric's fix doesn't work. It is common to use an additional address
> > on the lo device when doing routing protocols.
>
> Sigh.
>
> I just got back to looking through the rest of my failures in 2.6.37 and
> despite it looking like it worked when i tested it, your patch doesn't
> actually work on my real work load that has broken.
>
> At least your change that confirmed that the root problem is somewhere
> in the routing.
>
> Eric
The design problem behind all this is that sysctl disable_ipv6 as currently
implemented is passive (just changes a variable). It needs to be implemented
as a more active step that does the same thing as removing the interface from
ipv6. I will look into it after LCA.
next prev parent reply other threads:[~2011-01-22 22:39 UTC|newest]
Thread overview: 44+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-12-06 0:24 echo > 0 .../disable_ipv6 broken in 2.6.37-rc4 Eric W. Biederman
2010-12-06 0:33 ` Lorenzo Colitti
2010-12-06 0:39 ` Eric W. Biederman
2010-12-06 5:51 ` Eric W. Biederman
2010-12-06 16:10 ` Brian Haley
2010-12-08 21:29 ` Eric W. Biederman
2010-12-08 22:49 ` Brian Haley
2010-12-08 23:13 ` Eric W. Biederman
2010-12-08 23:49 ` Stephen Hemminger
2010-12-09 2:42 ` Eric W. Biederman
2010-12-09 3:18 ` Eric W. Biederman
2010-12-09 4:16 ` [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support Eric W. Biederman
2010-12-09 15:28 ` Brian Haley
2010-12-09 16:27 ` Stephen Hemminger
2010-12-09 19:22 ` Eric W. Biederman
2010-12-09 19:09 ` Eric W. Biederman
2010-12-09 19:16 ` Stephen Hemminger
2010-12-09 19:31 ` Eric W. Biederman
2010-12-09 20:20 ` David Miller
2010-12-09 20:20 ` David Miller
2010-12-09 22:51 ` Stephen Hemminger
2010-12-16 21:28 ` [RFC] ipv6: don't flush routes when setting loopback down Stephen Hemminger
2010-12-16 23:17 ` Eric W. Biederman
2010-12-17 1:18 ` Eric W. Biederman
2010-12-17 2:26 ` David Miller
2011-01-19 19:18 ` Jiri Bohac
2011-01-19 19:38 ` Stephen Hemminger
2011-01-19 19:56 ` Jiri Bohac
2011-01-19 20:01 ` Stephen Hemminger
2011-01-22 8:17 ` Eric W. Biederman
2011-01-22 22:39 ` Stephen Hemminger [this message]
2011-01-22 22:54 ` David Miller
2011-01-23 4:41 ` Stephen Hemminger
2011-01-23 5:42 ` David Miller
2011-01-23 8:24 ` Stephen Hemminger
2011-01-23 8:26 ` Stephen Hemminger
2011-01-23 9:15 ` [stable] " Willy Tarreau
2011-01-23 9:21 ` Stephen Hemminger
2011-01-23 10:34 ` Stephen Hemminger
2011-01-23 19:21 ` Eric W. Biederman
2011-01-23 19:57 ` [stable] " David Miller
2011-01-23 19:48 ` David Miller
2011-01-23 19:47 ` David Miller
2010-12-10 4:02 ` [PATCH] Fix 2.6.34-rc1 regression in disable_ipv6 support Stephen Hemminger
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=20110123093940.4f6075a3@s6510 \
--to=shemminger@vyatta.com \
--cc=brian.haley@hp.com \
--cc=davem@davemloft.net \
--cc=ebiederm@xmission.com \
--cc=jbohac@suse.cz \
--cc=lorenzo@google.com \
--cc=maheshkelkar@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=stable@kernel.org \
--cc=yoshfuji@linux-ipv6.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).