From: ebiederm@xmission•com (Eric W. Biederman)
To: dilip.daya@hp•com
Cc: "Serge E. Hallyn" <serge@hallyn•com>,
linux-kernel@vger•kernel.org,
containers@lists•linux-foundation.org, netdev@vger•kernel.org
Subject: Re: Network namespace and bonding WARNING at fs/proc/generic.c remove_proc_entry
Date: Fri, 06 Jul 2012 11:40:45 -0700 [thread overview]
Message-ID: <87pq88g2c2.fsf@xmission.com> (raw)
In-Reply-To: <1341597680.2829.22.camel@pro6455b.example.com> (Dilip Daya's message of "Fri, 06 Jul 2012 14:01:20 -0400")
Dilip Daya <dilip.daya@hp•com> writes:
> Hi Eric,
> We do need to move bonds between namespaces - because we require
> physical interfaces in each namespace -- we don't want the overheads of
> virtual interfaces, don't have the management infrastructure, and don't
> want to manufacture fake mac addresses that would be required for
> macvlan interfaces. Since the bonds are implicitly created in the host
> namespace, the only way we know to get bonds directly into the
> namespaces is to move them.
There about 3 ways to create bonding devices. One of those ways
is to create bonding devices when loading the module. Another
way is to create a bond device with "echo '+bond35 > /sys/class/net/bonding_masters".
them when loading the module, and my favorite is the standard way
"ip link add type bond". All but loading the bonding device work in the
network namespace you are in at the type.
> Would "NETDEV_UNREGISTER and NETDEV_REGISTER events to remove/add the
> per device proc files at the appropriate time." help in the case?
Yes. But since you can create the bonding device in the network
namespace you need it in, I don't see the point, of adding a code
path no one will test for 3 years at a time.
It seems easier to me to just not allow migration of bonding devices
and set peoples expectations a little lower. Especially given
the very complex user space interfaces.
On ther other hand if you want to write and test and generally own the
patch I will review it.
Eric
prev parent reply other threads:[~2012-07-06 18:40 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1340900320.3441.88.camel@pro6455b.example.com>
[not found] ` <20120705220749.GA11255@mail.hallyn.com>
2012-07-06 0:41 ` Network namespace and bonding WARNING at fs/proc/generic.c remove_proc_entry Eric W. Biederman
[not found] ` <87ehopu3e5.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-07-06 17:05 ` Serge E. Hallyn
[not found] ` <20120706170538.GA31679-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-07-06 18:01 ` Dilip Daya
2012-07-06 18:57 ` Eric W. Biederman
[not found] ` <87fw94g1kq.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-07-06 19:47 ` Serge E. Hallyn
[not found] ` <20120706194741.GA22113-7LNsyQBKDXoIagZqoN9o3w@public.gmane.org>
2012-07-09 20:51 ` [PATCH 1/2] bonding: Manage /proc/net/bonding/ entries from the netdev events Eric W. Biederman
[not found] ` <87y5ms3bfi.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-07-09 20:52 ` [PATCH 2/2] bonding: debugfs and network namespaces are incompatible Eric W. Biederman
[not found] ` <87sjd03bdw.fsf_-_-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-07-09 21:49 ` David Miller
2012-07-10 17:36 ` Jay Vosburgh
[not found] ` <367b470c-c3f5-4555-be11-02223125b741@email.android.com>
2012-07-10 19:13 ` Jay Vosburgh
2012-07-12 0:18 ` Eric W. Biederman
2012-07-12 1:57 ` Jay Vosburgh
2012-07-09 21:49 ` [PATCH 1/2] bonding: Manage /proc/net/bonding/ entries from the netdev events David Miller
2012-07-06 18:01 ` Network namespace and bonding WARNING at fs/proc/generic.c remove_proc_entry Dilip Daya
2012-07-06 18:40 ` Eric W. Biederman [this message]
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=87pq88g2c2.fsf@xmission.com \
--to=ebiederm@xmission$(echo .)com \
--cc=containers@lists$(echo .)linux-foundation.org \
--cc=dilip.daya@hp$(echo .)com \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=serge@hallyn$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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