From: ebiederm@xmission.com (Eric W. Biederman)
To: "Mahesh Bandewar (महेश बंडेवार)" <maheshb@google.com>
Cc: Eric Dumazet <edumazet@google.com>,
adobriyan@gmail.com, David Miller <davem@davemloft.net>,
xiyou.wangcong@gmail.com, linux-netdev <netdev@vger.kernel.org>
Subject: Re: RFC: bring UP 'lo' by default after creating new netns
Date: Thu, 29 Jun 2017 20:08:58 -0500 [thread overview]
Message-ID: <87efu22set.fsf@xmission.com> (raw)
In-Reply-To: <CAF2d9jhTcVgLHs_iqw+RRS=WhMtRF0ra5SygGMymuYQUW6HP0A@mail.gmail.com> (Mahesh Bandewar's message of "Thu, 29 Jun 2017 16:57:39 -0700")
"Mahesh Bandewar (महेश बंडेवार)" <maheshb@google.com> writes:
> Creation of new network namespace is almost always followed up by
> bringing up the loopback device.
>
> ip netns add foo
> ip -netns foo link set lo up
>
> I'm not sure if there are any consequences of bringing the device UP
> at the creation of network-namespace.
Hard coded in net/core/net_namespace.c:copy_net_ns is definitely the
wrong place in the code for something like this. If this lives anywhere
it should live in driver/net/loopback.c, or possibly in
net/core/dev.c:net_dev_init.
If we want this we want to match what we do when we the primary network
namespace. Just so that there are no unneeded surprises with network
namespaces.
Eric
next prev parent reply other threads:[~2017-06-30 1:16 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-29 23:57 RFC: bring UP 'lo' by default after creating new netns Mahesh Bandewar (महेश बंडेवार)
2017-06-30 1:08 ` Eric W. Biederman [this message]
2017-06-30 6:26 ` Mahesh Bandewar (महेश बंडेवार)
2017-06-30 12:38 ` [PATCH 1/8] signal/alpha: Document a conflict with SI_USER for SIGTRAP Eric W. Biederman
2017-06-30 12:38 ` Eric W. Biederman
[not found] ` <20170630123906.8865-1-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-02 14:13 ` Helge Deller
2017-07-02 14:13 ` Helge Deller
2017-07-02 14:13 ` Helge Deller
[not found] ` <20170702141320.GA32254-PwtjyNU/e7vkVFMGpb/cPg@public.gmane.org>
2017-07-14 10:59 ` Eric W. Biederman
2017-07-14 10:59 ` Eric W. Biederman
2017-07-14 10:59 ` Eric W. Biederman
2017-07-17 8:14 ` Michael Cree
2017-07-17 8:14 ` Michael Cree
2017-07-18 13:37 ` Eric W. Biederman
2017-07-18 13:37 ` Eric W. Biederman
[not found] ` <87fudz5lol.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-17 8:14 ` Michael Cree
2017-06-30 12:39 ` [PATCH 2/8] signal/ia64: Document a conflict with SI_USER with SIGFPE Eric W. Biederman
2017-06-30 12:39 ` Eric W. Biederman
2017-06-30 12:39 ` [PATCH 3/8] signal/sparc: " Eric W. Biederman
2017-06-30 12:39 ` Eric W. Biederman
[not found] ` <20170630123906.8865-3-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-30 16:45 ` David Miller
2017-06-30 16:45 ` David Miller
2017-06-30 16:45 ` David Miller
[not found] ` <20170630.124505.736865959393416284.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2017-06-30 18:13 ` Eric W. Biederman
2017-06-30 18:13 ` Eric W. Biederman
2017-06-30 18:13 ` Eric W. Biederman
[not found] ` <8737ahwdgr.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-18 13:43 ` Eric W. Biederman
2017-07-18 13:43 ` Eric W. Biederman
2017-07-18 13:43 ` Eric W. Biederman
2017-07-18 13:43 ` Eric W. Biederman
[not found] ` <87efu22set.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-06-30 12:38 ` [PATCH 1/8] signal/alpha: Document a conflict with SI_USER for SIGTRAP Eric W. Biederman
2017-06-30 12:39 ` [PATCH 2/8] signal/ia64: Document a conflict with SI_USER with SIGFPE Eric W. Biederman
2017-06-30 12:39 ` [PATCH 3/8] signal/sparc: " Eric W. Biederman
2017-06-30 12:39 ` [PATCH 4/8] signal/mips: " Eric W. Biederman
2017-06-30 12:39 ` Eric W. Biederman
2017-06-30 12:39 ` Eric W. Biederman
2017-06-30 12:39 ` [PATCH 5/8] signal/testing: Don't look for __SI_FAULT in userspace Eric W. Biederman
2017-06-30 12:39 ` Eric W. Biederman
2017-06-30 12:39 ` [PATCH 6/8] signal/x86: Fix SIGSYS handling in copy_siginfo_to_user32 Eric W. Biederman
2017-06-30 12:39 ` Eric W. Biederman
2017-06-30 12:39 ` Eric W. Biederman
2017-06-30 12:39 ` [PATCH 7/8] fcntl: Don't use ambiguous SIG_POLL si_codes Eric W. Biederman
2017-06-30 12:39 ` Eric W. Biederman
2017-06-30 12:39 ` [PATCH 8/8] signal: Remove kernel interal si_code magic Eric W. Biederman
2017-06-30 12:39 ` Eric W. Biederman
[not found] ` <20170630123906.8865-8-ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2017-07-12 22:36 ` Andrei Vagin
2017-07-12 22:36 ` Andrei Vagin
2017-07-12 23:08 ` Eric W. Biederman
[not found] ` <20170712223557.GA21885-1ViLX0X+lBJGNQ1M2rI3KwRV3xvJKrda@public.gmane.org>
2017-07-12 23:08 ` 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=87efu22set.fsf@xmission.com \
--to=ebiederm@xmission.com \
--cc=adobriyan@gmail.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=maheshb@google.com \
--cc=netdev@vger.kernel.org \
--cc=xiyou.wangcong@gmail.com \
/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.