From: ebiederm@xmission.com (Eric W. Biederman)
To: David Miller <davem@davemloft.net>
Cc: den@sw.ru, dlezcano@fr.ibm.com, netdev@vger.kernel.org,
xemul@openvz.org, containers@lists.osdl.org,
yoshfuji@linux-ipv6.org, benjamin.thery@bull.net
Subject: Re: [patch 1/1][NETNS][IPV6] protect addrconf from loopback registration
Date: Tue, 13 Nov 2007 05:59:38 -0700 [thread overview]
Message-ID: <m1r6iu2tdx.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20071112.142455.73541417.davem@davemloft.net> (David Miller's message of "Mon, 12 Nov 2007 14:24:55 -0800 (PST)")
David Miller <davem@davemloft.net> writes:
Well this is a weird way to get to this part of the conversation.
> From: "Denis V. Lunev" <den@sw.ru>
> Date: Mon, 12 Nov 2007 19:49:03 +0300
>
>> Unregister for a loopback in !init_net is a _valid_ operation and should
>> be clean, i.e. without kludges in the path. This is the only way to
>> check the ref-counting.
>
> For ipv6 the stack really wants to pin down the loopback
> device because we need a valid inet6_dev object to reference
> at all times in order to simplify the per-device SNMP
> statistic bumping.
>
> When a non-loopback device goes down, we point any existing
> references to that device's idev to the loopback one instead.
>
> I really consider taking down the loopback device to be
> an invalid operation at least how things are implemented
> currently.
In a secondary network namespace the current implementation
registers the loopback device before all other network devices
in a network namespace and it unregisters the loopback device
after all other network devices.
So we don't endanger the current scheme of pointing any existing
reference to the loopback device. In fact the current ipv6 addrconf_cleanup
largely does the same thing.
Unregistering the loopback device is definitely a case where we need
to tread very carefully.
Bug we absolutely need to do all of our cleanup for a network
namespace went it goes away and that includes removing the per network
namespace copy of the loopback device.
Eric
next prev parent reply other threads:[~2007-11-13 13:02 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20071112151953.052335971@mai.toulouse-stg.fr.ibm.com>
2007-11-12 15:19 ` [patch 1/1][NETNS][IPV6] protect addrconf from loopback registration Daniel Lezcano
2007-11-12 16:05 ` Denis V. Lunev
2007-11-12 16:11 ` Daniel Lezcano
2007-11-12 16:49 ` Denis V. Lunev
2007-11-12 16:59 ` Eric W. Biederman
2007-11-12 22:24 ` David Miller
2007-11-13 12:59 ` Eric W. Biederman [this message]
[not found] ` <473879C3.5020301-3ImXcnM4P+0@public.gmane.org>
2007-11-12 16:51 ` Eric W. Biederman
2007-11-12 17:01 ` Daniel Lezcano
2007-11-12 19:50 ` Eric W. Biederman
2007-11-13 1:52 ` YOSHIFUJI Hideaki / 吉藤英明
2007-11-13 13:11 ` Eric W. Biederman
2007-11-13 10:55 ` Daniel Lezcano
2007-11-12 21:00 ` Denis V. Lunev
2007-11-12 16:40 ` Eric W. Biederman
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=m1r6iu2tdx.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=benjamin.thery@bull.net \
--cc=containers@lists.osdl.org \
--cc=davem@davemloft.net \
--cc=den@sw.ru \
--cc=dlezcano@fr.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=xemul@openvz.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).