From: "Denis V. Lunev" <den@sw.ru>
To: Daniel Lezcano <dlezcano@fr.ibm.com>
Cc: davem@davemloft.net, netdev@vger.kernel.org, xemul@openvz.org,
ebiederm@xmission.com, containers@lists.osdl.org,
yoshfuji@linux-ipv6.org, Benjamin Thery <benjamin.thery@bull.net>
Subject: Re: [patch 1/1][NETNS][IPV6] protect addrconf from loopback registration
Date: Mon, 12 Nov 2007 19:49:03 +0300 [thread overview]
Message-ID: <473883FF.5010505@sw.ru> (raw)
In-Reply-To: <47387B31.20805@fr.ibm.com>
>> why should we care on down? we are destroying the device. It should
>> gone. All references to it should also gone. So, we should perform the
>> cleaning and remove all IPv6 addresses, so notifier should also work.
>
> We need to take care of netdev down, someone can put the loopback down
> if he wants.
>
>> The code relies on the "persistent" loopback and this is a _bad_ thing.
>> This is longstanding bug in the code, that the dst_entry should have a
>> valid reference to a device. This is the only purpose for a loopback
>> persistence. Though, at the namespace death no such entries must be and
>> this will be checked during unregister process. This patch definitely
>> breaks this assumption :(
>>
>> Namespaces are good to catch leakage using standard codepaths, so they
>> should be preserved as much as possible. So, _all_ normal down code
>> should be called for a loopback device in other than init_net context.
>
> I agree with you, this is a bug in ipv6 and the loopback; when playing
> with ipv6 we found that the loopback is still referenced 9 times when
> the system is shutdown.
Pff... I can't guess right now where the error can be :( We have
correct behavior of loopback even for IPv6 within OpenVZ. On down the
count is 0 and device is destroyed correctly without these kludges. So,
something is definitely wrong.
> The purpose of this patch is to protect the __actual__ code from the new
> loopback behavior. We are looking at a more generic approach with the
> namespace for ipv6, as you mentioned, namespaces are good for network
> leakage detection as we create several instances of the network stack.
The only kludge required is already in place. addrconf_ifdown has a
protection for init_net.
if (dev == init_net.loopback_dev && how == 1)
how = 0;
Other places should be untouched.
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.
next prev parent reply other threads:[~2007-11-12 16:49 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 [this message]
2007-11-12 16:59 ` Eric W. Biederman
2007-11-12 22:24 ` David Miller
2007-11-13 12:59 ` Eric W. Biederman
[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=473883FF.5010505@sw.ru \
--to=den@sw.ru \
--cc=benjamin.thery@bull.net \
--cc=containers@lists.osdl.org \
--cc=davem@davemloft.net \
--cc=dlezcano@fr.ibm.com \
--cc=ebiederm@xmission.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.