From: ebiederm@xmission•com (Eric W. Biederman)
To: Harald Welte <laforge@gnumonks•org>
Cc: Cong Wang <xiyou.wangcong@gmail•com>,
Linux Kernel Network Developers <netdev@vger•kernel.org>
Subject: Re: loosing netdevices with namespaces and unshare?
Date: Thu, 01 Jun 2017 02:48:01 -0500 [thread overview]
Message-ID: <8760gggnda.fsf@xmission.com> (raw)
In-Reply-To: <20170601070031.mdycexartsu33fyd@nataraja> (Harald Welte's message of "Thu, 1 Jun 2017 09:00:31 +0200")
Harald Welte <laforge@gnumonks•org> writes:
> Hi Eric,
>
> On Thu, Jun 01, 2017 at 01:32:49AM -0500, Eric W. Biederman wrote:
>
>> If a network device does not implement rntl_link_ops it is returned to
>> the initial network namespace. Anything else will loose physical
>> devices.
>
> Thanks a lot for your statement. This is a big relief, my line of
> thinking thus is confirmed: We shall not loose physical devices.
Rereading that I should have said:
We shall not lose physical devices.
We should let the loose to talk and say interesting things to the world.
>> Only for pure software based devices do we delete them. Perhaps your
>> sub interface implements rtnl_link_ops? Either that or something is
>> still holding a reference to your network namespace, which would prevent
>> the network device from being returned.
>
> My question is how to debug this further? Monitoring
> /proc/*/ns/net* showed that the ID of the namespace is gone after
> terminating my processes in the namespace. Short of adding printk() or
> playing with kprobes: to the related kernel code, how can I track the
> reference count or get an idea who might hold references?
You mentioned sub-interface. I would first look to see if your
sub-interface might possibly implement rtnl_link_ops.
For testing I would toss in a full fledged physical interface and
see if that pops back. Just to verify what you are seeing happening is
happening.
In your minimal test case of "unshare -Urn bash -c 'sleep 1; exit 0;'" I
can't imagine there is anything holding a reference. So it may come
down to adding some printks or playing with kprobes.
All of macvlans and vlans and anything I can think of as sub-interface
all implement rtnl_link_ops and will get deleted when a network
namespace exits. Which generally is what you want as it gives a very
nice cleanup.
Eric
next prev parent reply other threads:[~2017-06-01 7:54 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-30 22:07 loosing netdevices with namespaces and unshare? Harald Welte
2017-05-30 23:18 ` Cong Wang
2017-05-31 12:27 ` Harald Welte
2017-05-31 17:44 ` Cong Wang
2017-05-31 18:11 ` Harald Welte
2017-05-31 22:40 ` Cong Wang
2017-05-31 23:13 ` Harald Welte
2017-06-01 6:32 ` Eric W. Biederman
2017-06-01 7:00 ` Harald Welte
2017-06-01 7:48 ` Eric W. Biederman [this message]
2017-06-02 23:25 ` Cong Wang
2017-06-03 10:53 ` Eric W. Biederman
2017-05-30 23:41 ` David Ahern
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=8760gggnda.fsf@xmission.com \
--to=ebiederm@xmission$(echo .)com \
--cc=laforge@gnumonks$(echo .)org \
--cc=netdev@vger$(echo .)kernel.org \
--cc=xiyou.wangcong@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