netdev - Re: Deleting a network namespace

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 28 Mar 2013 07:00:52 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	David Shwatrz <dshwatrz@...il.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Deleting a network namespace

David Shwatrz <dshwatrz@...il.com> writes:

> Hello,
> I checked and indeed physical hardware are moved to init_net.
> I wonder how it is done, as in netns_delete() there is only
> umount2() and unlink() syscalls (might these syscalls trigger this
> movement to init_net)?

The mount holds a refcount to the network namespace, the unmount drops
that refcount.

> I really could not figure how this is
> implemented and where in code do we differentiate between physical and
> non physical devices.

When the refcount drops to zero put_net calls __put_net in
net/core/net_namespace.c which wiggles around and arranges
for cleanup_net to be called.

As for what happens to the network devices look at default_device_exit
and default_device_exit_batch in net/core/dev.c

As for the rest having software based network devices vanish is by
design and I can't think of a single reason why it would make sense to
do anything differently.  Depending on your configuration the initial
network namespace really isn't where you would want network devices to
be moved.   Think about what happens when you run your use can in a lxc
based container for example.

Eric
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html