All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Cedric Le Goater <clg@fr.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Containers <containers@lists.osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [patch -mm 0/4] mqueue namespace
Date: Thu, 19 Jun 2008 20:39:44 -0700	[thread overview]
Message-ID: <m1ve04vkov.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <m11w2syfmk.fsf@frodo.ebiederm.org> (Eric W. Biederman's message of "Thu, 19 Jun 2008 20:00:51 -0700")

ebiederm@xmission.com (Eric W. Biederman) writes:

> One way to fix that is to add a hidden directory to the mnt namespace.
> Where magic in kernel filesystems can be mounted.  Only visible
> with a magic openat flag.  Then:
>
> fd = openat(AT_FDKERN, ".", O_DIRECTORY)
> fchdir(fd);
> umount("./mqueue", MNT_DETACH);
> mount(("none", "./mqueue", "mqueue", 0, NULL);
>
> Would unshare the mqueue namespace.
>
> Implemented for plan9 this would solve a problem of how do you get
> access to all of it's special filesystems.  As only bind mounts
> and remote filesystem mounts are available.  For linux thinking about
> it might shake the conversation up a bit.

Thinking about this some more.  What is especially attractive if we do
all namespaces this way is that it solves two lurking problems.
1) How do you keep a namespace around without a process in it.
2) How do you enter a container.

If we could land the namespaces in the filesystem we could easily
persist them past the point where a process is present in one if we so
choose.

Entering a container would be a matter of replacing your current
namespaces mounts with namespace mounts take from the filesystem.

I expect performance would degrade in practice, but it is tempting
to implement it and run a benchmark and see if we can measure anything.

Eric

WARNING: multiple messages have this Message-ID (diff)
From: ebiederm@xmission.com (Eric W. Biederman)
To: Cedric Le Goater <clg@fr.ibm.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Linux Containers <containers@lists.osdl.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Pavel Emelianov <xemul@openvz.org>,
	Serge Hallyn <serue@us.ibm.com>
Subject: Re: [patch -mm 0/4] mqueue namespace
Date: Thu, 19 Jun 2008 20:39:44 -0700	[thread overview]
Message-ID: <m1ve04vkov.fsf@frodo.ebiederm.org> (raw)
In-Reply-To: <m11w2syfmk.fsf@frodo.ebiederm.org> (Eric W. Biederman's message of "Thu, 19 Jun 2008 20:00:51 -0700")

ebiederm@xmission.com (Eric W. Biederman) writes:

> One way to fix that is to add a hidden directory to the mnt namespace.
> Where magic in kernel filesystems can be mounted.  Only visible
> with a magic openat flag.  Then:
>
> fd = openat(AT_FDKERN, ".", O_DIRECTORY)
> fchdir(fd);
> umount("./mqueue", MNT_DETACH);
> mount(("none", "./mqueue", "mqueue", 0, NULL);
>
> Would unshare the mqueue namespace.
>
> Implemented for plan9 this would solve a problem of how do you get
> access to all of it's special filesystems.  As only bind mounts
> and remote filesystem mounts are available.  For linux thinking about
> it might shake the conversation up a bit.

Thinking about this some more.  What is especially attractive if we do
all namespaces this way is that it solves two lurking problems.
1) How do you keep a namespace around without a process in it.
2) How do you enter a container.

If we could land the namespaces in the filesystem we could easily
persist them past the point where a process is present in one if we so
choose.

Entering a container would be a matter of replacing your current
namespaces mounts with namespace mounts take from the filesystem.

I expect performance would degrade in practice, but it is tempting
to implement it and run a benchmark and see if we can measure anything.

Eric

  reply	other threads:[~2008-06-20  3:39 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20071128163728.177495768@fr.ibm.com>
2007-11-28 16:37 ` [patch -mm 1/4] mqueue namespace : add struct mq_namespace Cedric Le Goater
2007-11-28 16:37 ` [patch -mm 2/4] mqueue namespace : add unshare support Cedric Le Goater
2007-11-28 16:37 ` [patch -mm 3/4] mqueue namespace : enable the mqueue namespace Cedric Le Goater
2007-11-28 16:37 ` [patch -mm 4/4] mqueue namespace: adapt sysctl Cedric Le Goater
     [not found] ` <20071128163728.177495768-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-11-28 17:28   ` [patch -mm 0/4] mqueue namespace Pavel Emelyanov
2007-11-28 17:28     ` Pavel Emelyanov
2007-11-29  9:52     ` Cedric Le Goater
     [not found] ` <20071128164349.196734045@fr.ibm.com>
2007-11-28 17:32   ` [patch -mm 2/4] mqueue namespace : add unshare support Pavel Emelyanov
2007-11-29 10:28     ` Cedric Le Goater
     [not found]     ` <474DA61B.5030301-GEFAQzZX7r8dnm+yROfE0A@public.gmane.org>
2007-11-29 10:28       ` Cedric Le Goater
2007-11-29 10:28         ` Cedric Le Goater
2007-11-29 10:52         ` Andrew Morton
2007-11-29 13:57           ` Serge E. Hallyn
     [not found]         ` <474E944C.4020809-NmTC/0ZBporQT0dZR+AlfA@public.gmane.org>
2007-11-29 20:14           ` Oren Laadan
2007-11-29 20:14             ` Oren Laadan
2007-11-29 21:49             ` Eric W. Biederman
2007-11-29 15:03   ` Eric W. Biederman
2008-06-20  3:00 ` [patch -mm 0/4] mqueue namespace Eric W. Biederman
2008-06-20  3:39   ` Eric W. Biederman [this message]
2008-06-20  3:39     ` Eric W. Biederman
2008-06-20 14:53     ` Serge E. Hallyn
2008-08-29  9:46     ` Cedric Le Goater
2008-06-20 14:50   ` Serge E. Hallyn
2008-06-20 19:11     ` Eric W. Biederman
2007-11-28 16:37 Cedric Le Goater

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=m1ve04vkov.fsf@frodo.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=clg@fr.ibm.com \
    --cc=containers@lists.osdl.org \
    --cc=linux-kernel@vger.kernel.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.