netns: Delete virtual interfaces during namespace cleanup

There is no good reason to not support userspace specifying the network namespace during device creation and it seems a handy thing to do.

We have to be a little extra careful in this case to ensure that the network namespace exists through the point where we call register_netdevice.

In addition we need to pass the network namespace to the rtnl_link_ops.newlink method so we can properly create the new device in another namespace and have it be a vlan device of a device in our current network namespace.

In summary this patch makes ip link add somename netns NNN type sometype do the obvious thing instead of ignoring the network namespace parameter.

Signed-off-by Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>

---
 drivers/net/macvlan.c    |    4 ++--
 drivers/net/veth.c       |    5 +++--
 include/net/rtnetlink.h  |    3 ++-
 net/8021q/vlan_netlink.c |    4 ++--
 net/core/rtnetlink.c     |   17 ++++++++++++++++-
 5 files changed, 25 insertions(+), 8 deletions(-)

drivers/net/macvlan.c +2 -2

index 4239450..fc5933b 100644
@@ -416,7 +416,7 @@ static int macvlan_validate(struct nlattr *tb[], struct nlattr *data[])
 	return 0;
 }
 
-static int macvlan_newlink(struct net_device *dev,
+static int macvlan_newlink(struct net *net, struct net_device *dev,
 			   struct nlattr *tb[], struct nlattr *data[])
 {
 	struct macvlan_dev *vlan = netdev_priv(dev);

@@ -427,7 +427,7 @@ static int macvlan_newlink(struct net_device *dev,
 	if (!tb[IFLA_LINK])
 		return -EINVAL;
 
-	lowerdev = __dev_get_by_index(dev_net(dev), nla_get_u32(tb[IFLA_LINK]));
+	lowerdev = __dev_get_by_index(net, nla_get_u32(tb[IFLA_LINK]));
 	if (lowerdev == NULL)
 		return -ENODEV;
 

drivers/net/veth.c +3 -2

index 31cd817..3a2d818 100644
@@ -335,7 +335,7 @@ static int veth_validate(struct nlattr *tb[], struct nlattr *data[])
 
 static struct rtnl_link_ops veth_link_ops;
 
-static int veth_newlink(struct net_device *dev,
+static int veth_newlink(struct net *net, struct net_device *dev,
 			 struct nlattr *tb[], struct nlattr *data[])
 {
 	int err;

@@ -375,7 +375,7 @@ static int veth_newlink(struct net_device *dev,
 	else
 		snprintf(ifname, IFNAMSIZ, DRV_NAME "%%d");
 
-	peer = rtnl_create_link(dev_net(dev), ifname, &veth_link_ops, tbp);
+	peer = rtnl_create_link(net, ifname, &veth_link_ops, tbp);
 	if (IS_ERR(peer))
 		return PTR_ERR(peer);
 

@@ -383,6 +383,7 @@ static int veth_newlink(struct net_device *dev,
 		random_ether_addr(peer->dev_addr);
 
 	err = register_netdevice(peer);
+	put_net(peer->nd_net);
 	if (err < 0)
 		goto err_register_peer;
 

include/net/rtnetlink.h +2 -1

index 3c1895e..dbf546f 100644
@@ -55,7 +55,8 @@ struct rtnl_link_ops {
 	int			(*validate)(struct nlattr *tb[],
 					    struct nlattr *data[]);
 
-	int			(*newlink)(struct net_device *dev,
+	int			(*newlink)(struct net *net,
+					   struct net_device *dev,
 					   struct nlattr *tb[],
 					   struct nlattr *data[]);
 	int			(*changelink)(struct net_device *dev,

net/8021q/vlan_netlink.c +1 -1

index e9c91dc..e6190f7 100644
@@ -100,7 +100,7 @@ static int vlan_changelink(struct net_device *dev,
 	return 0;
 }
 
-static int vlan_newlink(struct net_device *dev,
+static int vlan_newlink(struct net *net, struct net_device *dev,
 			struct nlattr *tb[], struct nlattr *data[])
 {
 	struct vlan_dev_info *vlan = vlan_dev_info(dev);

net/8021q/vlan_netlink.c +0 -0

 	if (!real_dev)
 		return -ENODEV;
 

net/core/rtnetlink.c +13 -0

index 8862498..069b176 100644
@@ -1002,6 +1002,19 @@ struct net_device *rtnl_create_link(struct net *net, char *ifname,
 			goto err_free;
 	}
 
+	/* To support userspace specifying a network namespace during
+	 * device creation we grab the network namespace here and hold
+	 * it until just after register_netdevice to prevent races.
+	 */
+	if (!tb[IFLA_NET_NS_PID])
+		get_net(net);
+	else {
+		net = get_net_ns_by_pid(nla_get_u32(tb[IFLA_NET_NS_PID]));
+		if (IS_ERR(net)) {
+			err = PTR_ERR(net);
+			goto err_free;
+		}
+	}
 	dev_net_set(dev, net);
 	dev->rtnl_link_ops = ops;
 

net/core/rtnetlink.c +0 -0

 		if (err < 0 && !IS_ERR(dev))
 			free_netdev(dev);
 		return err;

drivers/net/macvlan.c static int macvlan_validate(struct nlattr *tb[], struct

Quoted 30 lines · Eric W. Biederman

There is no good reason to not support userspace specifying the network namespace during device creation and it seems a handy thing to do.

We have to be a little extra careful in this case to ensure that the network namespace exists through the point where we call register_netdevice.

In addition we need to pass the network namespace to the rtnl_link_ops.newlink method so we can properly create the new device in another namespace and have it be a vlan device of a device in our current network namespace.

In summary this patch makes ip link add somename netns NNN type sometype do the obvious thing instead of ignoring the network namespace parameter.

Signed-off-by Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>

---
 drivers/net/macvlan.c    |    4 ++--
 drivers/net/veth.c       |    5 +++--
 include/net/rtnetlink.h  |    3 ++-
 net/8021q/vlan_netlink.c |    4 ++--
 net/core/rtnetlink.c     |   17 ++++++++++++++++-
 5 files changed, 25 insertions(+), 8 deletions(-)

drivers/net/macvlan.c +0 -0

index 4239450..fc5933b 100644
@@ -416,7 +416,7 @@ static int macvlan_validate(struct nlattr *tb[], struct

nlattr *data[])

drivers/net/veth.c static int veth_validate(struct nlattr *tb[], struct

Quoted 22 lines

drivers/net/macvlan.c +2 -2

 	return 0;
 }
 
-static int macvlan_newlink(struct net_device *dev,
+static int macvlan_newlink(struct net *net, struct net_device *dev,
 			   struct nlattr *tb[], struct nlattr *data[])
 {
 	struct macvlan_dev *vlan = netdev_priv(dev);

@@ -427,7 +427,7 @@ static int macvlan_newlink(struct net_device *dev,
 	if (!tb[IFLA_LINK])
 		return -EINVAL;
 
- lowerdev = __dev_get_by_index(dev_net(dev), nla_get_u32(tb[IFLA_LINK]));
+	lowerdev = __dev_get_by_index(net, nla_get_u32(tb[IFLA_LINK]));
 	if (lowerdev == NULL)
 		return -ENODEV;
 

drivers/net/veth.c +0 -0

index 31cd817..3a2d818 100644
@@ -335,7 +335,7 @@ static int veth_validate(struct nlattr *tb[], struct

nlattr *data[])

Quoted 54 lines

drivers/net/veth.c +3 -2

 static struct rtnl_link_ops veth_link_ops;
 
-static int veth_newlink(struct net_device *dev,
+static int veth_newlink(struct net *net, struct net_device *dev,
 			 struct nlattr *tb[], struct nlattr *data[])
 {
 	int err;

@@ -375,7 +375,7 @@ static int veth_newlink(struct net_device *dev,
 	else
 		snprintf(ifname, IFNAMSIZ, DRV_NAME "%%d");
 
-	peer = rtnl_create_link(dev_net(dev), ifname, &veth_link_ops, tbp);
+	peer = rtnl_create_link(net, ifname, &veth_link_ops, tbp);
 	if (IS_ERR(peer))
 		return PTR_ERR(peer);
 

@@ -383,6 +383,7 @@ static int veth_newlink(struct net_device *dev,
 		random_ether_addr(peer->dev_addr);
 
 	err = register_netdevice(peer);
+	put_net(peer->nd_net);
 	if (err < 0)
 		goto err_register_peer;
 

include/net/rtnetlink.h +2 -1

index 3c1895e..dbf546f 100644
@@ -55,7 +55,8 @@ struct rtnl_link_ops {
 	int			(*validate)(struct nlattr *tb[],
 					    struct nlattr *data[]);
 
-	int			(*newlink)(struct net_device *dev,
+	int			(*newlink)(struct net *net,
+					   struct net_device *dev,
 					   struct nlattr *tb[],
 					   struct nlattr *data[]);
 	int			(*changelink)(struct net_device *dev,

net/8021q/vlan_netlink.c +1 -1

index e9c91dc..e6190f7 100644
@@ -100,7 +100,7 @@ static int vlan_changelink(struct net_device *dev,
 	return 0;
 }
 
-static int vlan_newlink(struct net_device *dev,
+static int vlan_newlink(struct net *net, struct net_device *dev,
 			struct nlattr *tb[], struct nlattr *data[])
 {
 	struct vlan_dev_info *vlan = vlan_dev_info(dev);

@@ -112,7 +112,7 @@ static int vlan_newlink(struct net_device *dev,
 

net/8021q/vlan_netlink.c static int vlan_newlink(struct net_device *dev, · line 115

Quoted 4 lines

net/8021q/vlan_netlink.c +1 -1

 	if (!tb[IFLA_LINK])
 		return -EINVAL;
- real_dev = __dev_get_by_index(dev_net(dev), nla_get_u32(tb[IFLA_LINK]));
+	real_dev = __dev_get_by_index(net, nla_get_u32(tb[IFLA_LINK]));

Hmm, if the macvlan is created inside a namespace, the network namespace specified in the parameter function will not be the namespace where belongs IFLA_LINK and the __dev_get_by_index will fail, no ?

net/core/rtnetlink.c struct net_device *rtnl_create_link(struct net *net,

Quoted 8 lines

net/8021q/vlan_netlink.c +0 -0

 	if (!real_dev)
 		return -ENODEV;
 

net/core/rtnetlink.c +0 -0

index 8862498..069b176 100644
@@ -1002,6 +1002,19 @@ struct net_device *rtnl_create_link(struct net *net,

char *ifname,

Quoted 28 lines

net/core/rtnetlink.c +14 -1

 			goto err_free;
 	}
 
+	/* To support userspace specifying a network namespace during
+	 * device creation we grab the network namespace here and hold
+	 * it until just after register_netdevice to prevent races.
+	 */
+	if (!tb[IFLA_NET_NS_PID])
+		get_net(net);
+	else {
+		net = get_net_ns_by_pid(nla_get_u32(tb[IFLA_NET_NS_PID]));
+		if (IS_ERR(net)) {
+			err = PTR_ERR(net);
+			goto err_free;
+		}
+	}
 	dev_net_set(dev, net);
 	dev->rtnl_link_ops = ops;
 

@@ -1150,10 +1163,12 @@ replay:
 		if (IS_ERR(dev))
 			err = PTR_ERR(dev);
 		else if (ops->newlink)
-			err = ops->newlink(dev, tb, data);
+			err = ops->newlink(net, dev, tb, data);
 		else
 			err = register_netdevice(dev);
 

net/core/rtnetlink.c replay: · line 1171

Quoted 2 lines

net/core/rtnetlink.c +2 -0

+		if (!IS_ERR(dev))
+			put_net(dev->nd_net);

If there is an error in ops->newlink or register_netdevice, we will exit without releasing the net refcount.

When physical devices are inside of network namespace and that network namespace terminates we can not make them go away. We have to keep them and moving them to the initial network namespace is the best we can do.

For virtual devices left in a network namespace that is exiting we have no need to preserve them and we now have the infrastructure that allows us to delete them. So delete virtual devices when we exit a network namespace. Keeping the necessary user space clean up after a network namespace exits much more tractable.

This patch removes much of the need for user space clean up code to run after a network namespace exits.

Signed-off-by Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>

---
 net/core/dev.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

net/core/dev.c +6 -0

index 7091040..f3476d4 100644
@@ -4844,6 +4844,12 @@ static void __net_exit default_device_exit(struct net *net)
 		if (dev->features & NETIF_F_NETNS_LOCAL)
 			continue;
 
+		/* Delete virtual devices */
+		if (dev->rtnl_link_ops && dev->rtnl_link_ops->dellink) {
+			dev->rtnl_link_ops->dellink(dev);
+			continue;
+		}
+
 		/* Push remaing network devices to init_net */
 		snprintf(fb_name, IFNAMSIZ, "dev%d", dev->ifindex);
 		err = dev_change_net_namespace(dev, &init_net, fb_name);

I agree that will make the life easier for user space developer :)

I have a few questions about this new behaviour.

After discussing with Benjamin, this patch means an user can no longer manage a pool of virtual devices because they will be automatically destroyed when the namespace exits. I don't think it is a big concern, but just in case I am asking :)

Another point, at present, the virtual devices go back to the initial network namespace when the namespace dies, and this behaviour is used to track the namespace life cycle. With this patch we have no way to know when the network namespace has exited. So we can have the last process exiting the network namespace, but the network namespace can stay alive (eg. some sockets still have buffer to send) ?

AFAIR, Pavel told us about a patch extending the "wait" semantic and pass namespace options to wait for. Is that right Pavel ? Shouldn't we apply this path before deleting the virtual network devices ?

Quoted 9 lines · Daniel Lezcano

I agree that will make the life easier for user space developer :)

I have a few questions about this new behaviour.

After discussing with Benjamin, this patch means an user can no longer manage a pool of virtual devices because they will be automatically destroyed when the namespace exits. I don't think it is a big concern, but just in case I am asking :)

Quoted 6 lines

Another point, at present, the virtual devices go back to the initial network namespace when the namespace dies, and this behaviour is used to track the namespace life cycle. With this patch we have no way to know when the network namespace has exited. So we can have the last process exiting the network namespace, but the network namespace can stay alive (eg. some sockets still have buffer to send) ?

Depending on the network interfaces going back to the initial network namespace is problematic in the long term because is breaks recursive containers. I can't see any behavior that does that as anything other than a bug.

Especially
as I already have production uses for recursive containers.

Quoted 3 lines

AFAIR, Pavel told us about a patch extending the "wait" semantic and pass namespace options to wait for. Is that right Pavel ? Shouldn't we apply this path before deleting the virtual network devices ?

Tell you what. I will post in a bit my patchset that makes /proc/net it's own filesystem, that magically mounts on /proc/self/net. It is a long stupid story why I haven't posted it publicly. At which point we have complete visibility into when a network namespace exits and if we need to be able to wait for it we can just implement a poll method on the root directory.

That is simple and will work quite nicely in the long term, and gives us a lot more visibility than a simple this namespace has exited bit.

Perhaps, I am misunderstanding your sentence :) But just in case, let me clarify my idea.

If you have a TCP connection with a send queue not empty (the kernel has buffered the data the application has sent), when your process exits because the last socket write was done in userspace, the TCP socket will be orphan but still there taking a ref count on your network namespace. Hence the process and the network namespace life cycles is not correlated. This is a correct behavior, it is not a bug.

Can a process outside of the network namespace look at this directory even if there are no more processes running inside the namespace ?

Quoted 2 lines

That is simple and will work quite nicely in the long term, and gives us a lot more visibility than a simple this namespace has exited bit.

This is nice :)

Shouldn't you send /proc/net filesystem patch before sending the virtual network devices autodestroy patch ?

Quoted 9 lines · Daniel Lezcano

Perhaps, I am misunderstanding your sentence :) But just in case, let me clarify my idea.

If you have a TCP connection with a send queue not empty (the kernel has buffered the data the application has sent), when your process exits because the last socket write was done in userspace, the TCP socket will be orphan but still there taking a ref count on your network namespace. Hence the process and the network namespace life cycles is not correlated. This is a correct behavior, it is not a bug.

Agreed, letting the network stack finish sending the last bits of data from sockets is not a bug.

The problem I see is having a veth device that exists in a child container, and the application waiting for the child device to return to the current network namespace. Since we always return network devices to the initial network namespace waiting for a device in a child container does not work in a recursive container. And thus is a bug.

Quoted 2 lines

Can a process outside of the network namespace look at this directory even if there are no more processes running inside the namespace ?

If you mount it somewhere besides /proc/self/net yes.

Say: mount --bind /proc/self/net /tmp/net

Quoted 6 lines

Quoted 2 lines

That is simple and will work quite nicely in the long term, and gives us a lot more visibility than a simple this namespace has exited bit.

This is nice :)

Shouldn't you send /proc/net filesystem patch before sending the virtual network devices autodestroy patch ?

Well there is the cheap trick with this patch of waiting until the local end of veth dies.

Quoted 2 lines · Eric W. Biederman

Well there is the cheap trick with this patch of waiting until the local end of veth dies.

I actually use veth, macvlan, empty netns and physical. But if you are planning the send netns fs soon, I guess I can live with that a time.

From: Daniel Lezcano <dlezcano-NmTC/[email protected]>
Date: Tue, 07 Oct 2008 14:07:00 +0200

Quoted 3 lines

Quoted 2 lines · Eric W. Biederman

Well there is the cheap trick with this patch of waiting until the local end of veth dies.

Quoted 3 lines

I actually use veth, macvlan, empty netns and physical. But if you are planning the send netns fs soon, I guess I can live with that a time.

Are we anywhere near consensus with this patch?

Please resubmit once there is some agreement.

Quoted 5 lines · Eric W. Biederman

When physical devices are inside of network namespace and that network namespace terminates we can not make them go away. We have to keep them and moving them to the initial network namespace is the best we can do.

Quoted 8 lines

For virtual devices left in a network namespace that is exiting we have no need to preserve them and we now have the infrastructure that allows us to delete them. So delete virtual devices when we exit a network namespace. Keeping the necessary user space clean up after a network namespace exits much more tractable.

This patch removes much of the need for user space clean up code to run after a network namespace exits.

I agree that will make the life easier for user space developer :)

I have a few questions about this new behaviour.

After discussing with Benjamin, this patch means an user can no longer manage a pool of virtual devices because they will be automatically destroyed when the namespace exits. I don't think it is a big concern, but just in case I am asking :)

Another point, at present, the virtual devices go back to the initial network namespace when the namespace dies, and this behaviour is used to track the namespace life cycle. With this patch we have no way to know when the network namespace has exited. So we can have the last process exiting the network namespace, but the network namespace can stay alive (eg. some sockets still have buffer to send) ?

AFAIR, Pavel told us about a patch extending the "wait" semantic and pass namespace options to wait for. Is that right Pavel ? Shouldn't we apply this path before deleting the virtual network devices ?

Thanks.
-- Daniel

Quoted 22 lines

Signed-off-by Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>

---
 net/core/dev.c |    6 ++++++
 1 files changed, 6 insertions(+), 0 deletions(-)

net/core/dev.c +6 -0

index 7091040..f3476d4 100644
@@ -4844,6 +4844,12 @@ static void __net_exit default_device_exit(struct net *net)
 		if (dev->features & NETIF_F_NETNS_LOCAL)
 			continue;
 
+		/* Delete virtual devices */
+		if (dev->rtnl_link_ops && dev->rtnl_link_ops->dellink) {
+			dev->rtnl_link_ops->dellink(dev);
+			continue;
+		}
+
 		/* Push remaing network devices to init_net */
 		snprintf(fb_name, IFNAMSIZ, "dev%d", dev->ifindex);
 		err = dev_change_net_namespace(dev, &init_net, fb_name);

I remember that I promised to prepare the wait-extending patch. But I haven't manage to find time for this, sorry :( In a month or two I will finish one time-hungry task and hopefully be able to do it.

As far as this particular patch is concerned.

All the virtual devices we have now in namespaces (vlan and tunnels) kill themselves *before* this code is called. But even if we try to move this destruction from modules to here, we'll be in a tricky situation, when the e.g. ipip module has already kfree-d the net_ipip structure, while none of ipip devices are released yet.

If we try to look in the future - if we ever have a virtual device driver, that will be able to create its devices in namespace, we'll have to destroy all these devices *before* (or inside) this driver's net->exit callback is called, but this patch dies the ->dellink call at the very end, i.e. *after* any potential ->exit callback.

Eric - did you see any device, that was ->dellink-ed by this patch?

Quoted 18 lines · Pavel Emelyanov

I remember that I promised to prepare the wait-extending patch. But I haven't manage to find time for this, sorry :( In a month or two I will finish one time-hungry task and hopefully be able to do it.

As far as this particular patch is concerned.

All the virtual devices we have now in namespaces (vlan and tunnels) kill themselves *before* this code is called. But even if we try to move this destruction from modules to here, we'll be in a tricky situation, when the e.g. ipip module has already kfree-d the net_ipip structure, while none of ipip devices are released yet.

If we try to look in the future - if we ever have a virtual device driver, that will be able to create its devices in namespace, we'll have to destroy all these devices *before* (or inside) this driver's net->exit callback is called, but this patch dies the ->dellink call at the very end, i.e. *after* any potential ->exit callback.

Quoted 1 line

Eric - did you see any device, that was ->dellink-ed by this patch?

macvlan, veth, and dummy interfaces. Basically everything I use this deletes the virtual interfaces, instead of sending them back to the initial network namespace.

Quoted 1 line

From the looks of the code vlans are also be handled.

Things like tun/tap and ipip are handled in the exit methods and I have no problem with that, although I do wonder if we are handling moving or refusing to move them between namespaces properly.

For devices that don't need a dedicated virtual interface in every network namespace this certainly looks like the easiest way to handle them, as the driver doesn't need to a thing about network namespaces and the right thing just happens.

Eric

I have been tracking for a while a case where when the network namespace exits the cleanup gets stck in an endless precessess of:

unregister_netdevice: waiting for lo to become free. Usage count = 3
unregister_netdevice: waiting for lo to become free. Usage count = 3
unregister_netdevice: waiting for lo to become free. Usage count = 3
unregister_netdevice: waiting for lo to become free. Usage count = 3
unregister_netdevice: waiting for lo to become free. Usage count = 3
unregister_netdevice: waiting for lo to become free. Usage count = 3
unregister_netdevice: waiting for lo to become free. Usage count = 3

It turns out that if you listen on a multicast address an unsubscribe
packet is sent when the network device goes down. If you shutdown
the network namespace without carefully cleaning up this can trigger the unsubscribe packet to be sent over the loopback interface while the network namespace is going down.

All of which is fine except when we drop the packet and forget to free it leaking the skb and the dst entry attached to. As it turns out the dst entry hold a reference to the idev which holds the dev and keeps everything from being cleaned up. Yuck!

By fixing my earlier thinko and add the needed kfree_skb and everything cleans up beautifully.

Signed-off-by Eric W. Biederman <[email protected]>

I was recently hunting a bug that occurred in network namespace cleanup. In looking at the code it became apparrent that we have and will continue to have cases where if we have anything going on in a network namespace there will be assumptions that the
loopback device is present. Things like sending igmp unsubscribe
messages when we bring down network devices invokes the routing code which assumes that at least the loopback driver is present.

Therefore to avoid magic initcall ordering hackery that is hard to follow and hard to get right insert a call to register the
loopback device directly from net_dev_init(). This guarantes
that the loopback device is the first device registered and the last network device to go away.

Signed-off-by Eric W. Biederman <[email protected]>

I was recently hunting a bug that occurred in network namespace cleanup. In looking at the code it became apparrent that we have and will continue to have cases where if we have anything going on in a network namespace there will be assumptions that the
loopback device is present. Things like sending igmp unsubscribe
messages when we bring down network devices invokes the routing code which assumes that at least the loopback driver is present.

Therefore to avoid magic initcall ordering hackery that is hard to follow and hard to get right insert a call to register the
loopback device directly from net_dev_init(). This guarantes
that the loopback device is the first device registered and the last network device to go away.

But do it carefully so we register the loopback device after we clear dev_boot_phase.

Signed-off-by Eric W. Biederman <[email protected]>

We need to setup the network namespace state before we register the notifier. Otherwise if a network device is already registered we get a nasty NULL pointer dereference.

Signed-off-by Eric W. Biederman <[email protected]>

Dave can you please drop this one for the moment.

I cleaned up my patch after the basic testing was over and the result is a kernel that won't boot. So if we can prevent this patch from spreading and breaking a git-bisect that would be great.

I will follow up in a moment with a properly tested version. My apologies.

Dave can you please drop this one for the moment.

I cleaned up my patch after the basic testing was over and the result is a kernel that won't boot. So if we can prevent this patch from spreading and breaking a git-bisect that would be great.

I will follow up in a moment with a properly tested version. My apologies.

I'm putting a revert changeset in there, then your two new patches on top.

I'm not screwing up my GIT tree for everyone who pulls from me just because you can't be bothered to test the actual changes you send me.

When physical devices are inside of network namespace and that network namespace terminates we can not make them go away. We have to keep them and moving them to the initial network namespace is the best we can do.

For virtual devices left in a network namespace that is exiting we have no need to preserve them and we now have the infrastructure that allows us to delete them. So delete virtual devices when we exit a network namespace. Keeping the necessary user space clean up after a network namespace exits much more tractable.

Acked-by Daniel Lezcano <dlezcano-NmTC/[email protected]>

Acked-by Pavel Emelyanov <[email protected]>

Signed-off-by Eric W. Biederman <ebiederm-aS9lmoZGLiVWk0Htik3J/[email protected]>