From: ebiederm@xmission•com (Eric W. Biederman)
To: Renato Westphal <renatowestphal@gmail•com>
Cc: netdev@vger•kernel.org, kaber@trash•net,
David Lamparter <equinox@diac24•net>
Subject: Re: Move interface across network namespaces
Date: Thu, 18 Aug 2011 16:12:57 -0700 [thread overview]
Message-ID: <m14o1e71qe.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <CAChaeg=1WSU0webhYDpQcnq3cJje17FQ5Z8rypD8sdkyzcLT-g@mail.gmail.com> (Renato Westphal's message of "Mon, 15 Aug 2011 10:10:24 -0300")
Renato Westphal <renatowestphal@gmail•com> writes:
> I forgot to mention that I'm using kernel v2.6.35 (with a lot of
> backports). For future reference, the commit 3b27e105550f7c4a ("netns:
> keep vlan slaves on master netns move", merged into v2.6.37-rc1) fixes
> this problem.
Which makes me silly as I now remember reviewing that patch.
>>>> * The target network namespace sends a RTM_NEWLINK netlink message
>>>> when an interface is moved to it. In the other hand, the source
>>>> network namespace doesn't sends a RTM_DELLINK message when an
>>>> interface is moved from it. This is very annoying because user space
>>>> applications (such as zebra) can't detect some interface moving
>>>> operations and then get into an inconsistent state. Anyone knows if
>>>> there's a workaround for this?
>>>
>>> Not getting RTM_DELLINK is a bug. The device registration and
>>> unregistration code has changed since dev_change_net_namespace was
>>> written and apparently one of the changes failed to update
>>> dev_change_net_namespace.
>>>
>>
>> Good, that makes a lot more sense. In the kernel 2.6.32.43 the
>> RTM_DELLINK netlink message is sent when a network interface is moved
>> from a network namespace. The same doesn't happens in the kernel
>> 2.6.35.13. I'll try to isolate the problem some more.
>
> Well, this regression was introduced by commit a2835763e130c343ac,
> which was merged into v2.6.34. Reverting parts of this commit makes
> the problem go away but breaks the support of "specifying device flags
> during device creation". I don't know the best way to fix this... any
> ideas?
Everything going through dev_change_net_namespace already needs to be
in the initialized state. So it looks like we just need to do:
Does the patch below work for you?
Eric
---
diff --git a/net/core/dev.c b/net/core/dev.c
index 17d67b5..bfbde69 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6108,6 +6108,8 @@ int dev_change_net_namespace(struct net_device *dev, struct net *net, const char
call_netdevice_notifiers(NETDEV_UNREGISTER, dev);
call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
+ rtmsg_ifinfo(RTM_DELLINK, dev, ~0U);
+
/*
* Flush the unicast and multicast chains
*/
next prev parent reply other threads:[~2011-08-18 23:13 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-11 0:31 Move interface across network namespaces Renato Westphal
2011-08-11 7:13 ` Eric W. Biederman
2011-08-11 18:29 ` Renato Westphal
2011-08-15 13:10 ` Renato Westphal
2011-08-18 23:12 ` Eric W. Biederman [this message]
2011-08-19 14:38 ` Renato Westphal
2011-10-21 16:24 ` [PATCH] rtnetlink: Add missing manual netlink notification in dev_change_net_namespaces Eric W. Biederman
2011-10-24 7:03 ` David Miller
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=m14o1e71qe.fsf@fess.ebiederm.org \
--to=ebiederm@xmission$(echo .)com \
--cc=equinox@diac24$(echo .)net \
--cc=kaber@trash$(echo .)net \
--cc=netdev@vger$(echo .)kernel.org \
--cc=renatowestphal@gmail$(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