Linux Container Development
 help / color / mirror / Atom feed
From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)
To: Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
Cc: Linux Containers
	<containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org>,
	"Denis V. Lunev" <den-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>,
	David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>,
	Pavel Emelianov <xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
Subject: Re: [PATCH] netns: Delete virtual interfaces during namespace cleanup
Date: Tue, 07 Oct 2008 04:45:40 -0700	[thread overview]
Message-ID: <m1fxn839y3.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <48EB4679.1040602-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> (Daniel Lezcano's message of "Tue, 07 Oct 2008 13:22:33 +0200")

Daniel Lezcano <dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org> writes:

> 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.

> 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

>> 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.

Eric

  parent reply	other threads:[~2008-10-07 11:45 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-03  0:39 [PATCH] netns: Delete virtual interfaces during namespace cleanup Eric W. Biederman
     [not found] ` <m18wt6v7eb.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-10-03  0:46   ` [PATCH] net: Support specifying the network namespace upon device creation Eric W. Biederman
     [not found]     ` <m1vdwatshs.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-10-07 12:20       ` Daniel Lezcano
     [not found]         ` <48EB541A.5070306-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-07 23:38           ` Eric W. Biederman
2008-10-07 10:16   ` [PATCH] netns: Delete virtual interfaces during namespace cleanup Daniel Lezcano
     [not found]     ` <48EB36FC.4000008-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-07 10:41       ` Eric W. Biederman
     [not found]         ` <m1ej2s7kmj.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-10-07 11:22           ` Daniel Lezcano
     [not found]             ` <48EB4679.1040602-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-07 11:45               ` Eric W. Biederman [this message]
     [not found]                 ` <m1fxn839y3.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-10-07 12:07                   ` Daniel Lezcano
     [not found]                     ` <48EB50E4.3060303-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2008-10-07 23:08                       ` David Miller
     [not found]                         ` <20081007.160807.32968959.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2008-10-08  8:19                           ` Daniel Lezcano
2008-10-07 10:52       ` Pavel Emelyanov
     [not found]         ` <48EB3F72.5090201-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-10-07 11:28           ` Eric W. Biederman
     [not found]             ` <m1d4ic4pbr.fsf-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-10-08 12:34               ` Pavel Emelyanov
     [not found]                 ` <48ECA8D2.4090406-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2008-11-05 23:22                   ` [PATCH 1/3] " Eric W. Biederman
2008-11-05 23:25                     ` [PATCH 2/3] net: Guaranetee the proper ordering of the loopback device Eric W. Biederman
2008-11-05 23:27                       ` [PATCH 3/3] net: Don't leak packets when a netns is going down Eric W. Biederman
2008-11-06  0:00                         ` David Miller
2008-11-06  0:00                       ` [PATCH 2/3] net: Guaranetee the proper ordering of the loopback device David Miller
2008-11-06 13:02                         ` Eric W. Biederman
2008-11-06 15:34                           ` [PATCH 1/2] net: fib_rules ordering fixes Eric W. Biederman
2008-11-06 15:36                             ` [PATCH 2/2] net: Guaranetee the proper ordering of the loopback device. v2 Eric W. Biederman
2008-11-08  6:55                               ` David Miller
2008-11-08  6:54                             ` [PATCH 1/2] net: fib_rules ordering fixes David Miller
2008-11-06 21:20                           ` [PATCH 2/3] net: Guaranetee the proper ordering of the loopback device David Miller
2008-11-08  6:53                           ` David Miller
2008-11-08  7:13                             ` Eric W. Biederman
     [not found]                     ` <m14p2l4v2l.fsf_-_-B27657KtZYmhTnVgQlOflh2eb7JE58TQ@public.gmane.org>
2008-11-06  0:00                       ` [PATCH 1/3] netns: Delete virtual interfaces during namespace cleanup David Miller
  -- strict thread matches above, loose matches on Subject: below --
2008-07-11 20:07 [PATCH] " 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=m1fxn839y3.fsf@frodo.ebiederm.org \
    --to=ebiederm-as9lmozglivwk0htik3j/w@public.gmane.org \
    --cc=containers-qjLDD68F18O7TbgM5vRIOg@public.gmane.org \
    --cc=davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org \
    --cc=den-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
    --cc=dlezcano-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org \
    --cc=xemul-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox