OpenVZ Forum - RDF feed
type: channel
items: [PATCH 1/1] containers: implement nsproxy containers subsystem
items: Re: [PATCH 1/1] containers: implement nsproxy containers subsystem

[PATCH 1/1] containers: implement nsproxy containers subsystem
type: item
description: >From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <serue@us.ibm.com> Date: Mon, 4 Jun 2007 14:18:52 -0400 Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem When a task enters a new namespace via a clone() or unshare(), a new container is created and the task moves into it. This enables tracking - and applying resource controls - to virtual servers, resource jobs, often logins (using per-user namespaces), and in general any application of per-process namespaces. This version uses an ida to generate a unique id for auto-created containers, i.e. those created through container_clone(). After a container is created, it can be renamed to a more useful name if so desired. The original id isn't released until the container is destroyed. (This could be fixed at container_rename() if it was deemed desireable) There is just one ida for all containers, because an ida per container to track ids used for child containers would take a great deal of space, and probably isn't very useful. Changelog: Use an ida to generate unique ids for auto-created containers. Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- include/linux/container.h | 2 + include/linux/container_subsys.h | 6 ++ include/linux/nsproxy.h | 7 +++ init/Kconfig | 9 ++++ kernel/Makefile | 1 + kernel/container.c | 52 ++++++++++++++++---- kernel/ns_container.c | 99 ++++++++++++++++++++++++++++++++++++++ kernel/nsproxy.c | 16 ++++++ 8 files changed, 183 insertions(+), 9 deletions(-) create mode 100644 kernel/ns_container.c diff --git a/include/linux/container.h b/include/linux/container.h index 37c0bdf..2f8ee47 100644 --- a/include/linux/container.h +++ b/include/linux/container.h @@ -87,6 +87,8 @@ struct container { /* Private pointers for each registered subsystem */ struct container_subsys_state *subsys[CONTAINER_SUBSYS_COUNT]; + int unique_id; /* usually -1, set to >=0 in container_clone() */ + struct containerfs_root *root; struct container *top_co…
creator: serue
date: 2007-06-04T18:50:34-00:00

Re: [PATCH 1/1] containers: implement nsproxy containers subsystem
type: item
description: Sorry, didn't paste in my comment at the top that this is again not at all for inclusion, and barely tested, but mainly to get comment i.e. on the way the naming is done. thanks, -serge Quoting Serge E. Hallyn (serue@us.ibm.com): > >From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001 > From: Serge E. Hallyn <serue@us.ibm.com> > Date: Mon, 4 Jun 2007 14:18:52 -0400 > Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem > > When a task enters a new namespace via a clone() or unshare(), a new > container is created and the task moves into it. This enables > tracking - and applying resource controls - to virtual servers, > resource jobs, often logins (using per-user namespaces), and in > general any application of per-process namespaces. > > This version uses an ida to generate a unique id for auto-created > containers, i.e. those created through container_clone(). After > a container is created, it can be renamed to a more useful name if > so desired. The original id isn't released until the container is > destroyed. (This could be fixed at container_rename() if it was > deemed desireable) > > There is just one ida for all containers, because an ida per container > to track ids used for child containers would take a great deal of > space, and probably isn't very useful. > > Changelog: > Use an ida to generate unique ids for auto-created containers. > > Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> > --- > include/linux/container.h | 2 + > include/linux/container_subsys.h | 6 ++ > include/linux/nsproxy.h | 7 +++ > init/Kconfig | 9 ++++ > kernel/Makefile | 1 + > kernel/container.c | 52 ++++++++++++++++---- > kernel/ns_container.c | 99 ++++++++++++++++++++++++++++++++++++++ > kernel/nsproxy.c | 16 ++++++ > 8 files changed, 183 insertions(+), 9 deletions(-) > create mode 100644 kernel/ns_container.c > > diff --git a/include/linux/container.h b/include/linux/container.h > index 37c0bdf..2f8ee47 100644 > --- a/include/linux/container…
creator: serue
date: 2007-06-04T19:05:38-00:00

Re: [PATCH 1/1] containers: implement nsproxy containers subsystem
type: item
description: Serge E. Hallyn wrote: >>From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001 > From: Serge E. Hallyn <serue@us.ibm.com> > Date: Mon, 4 Jun 2007 14:18:52 -0400 > Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem > > When a task enters a new namespace via a clone() or unshare(), a new > container is created and the task moves into it. This enables I have a design question. How the child that has a new namespace guesses what id this namespace has in containers? > tracking - and applying resource controls - to virtual servers, > resource jobs, often logins (using per-user namespaces), and in > general any application of per-process namespaces. > > This version uses an ida to generate a unique id for auto-created > containers, i.e. those created through container_clone(). After > a container is created, it can be renamed to a more useful name if > so desired. The original id isn't released until the container is > destroyed. (This could be fixed at container_rename() if it was > deemed desireable) > > There is just one ida for all containers, because an ida per container > to track ids used for child containers would take a great deal of > space, and probably isn't very useful. > > Changelog: > Use an ida to generate unique ids for auto-created containers. > > Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> > --- > include/linux/container.h | 2 + > include/linux/container_subsys.h | 6 ++ > include/linux/nsproxy.h | 7 +++ > init/Kconfig | 9 ++++ > kernel/Makefile | 1 + > kernel/container.c | 52 ++++++++++++++++---- > kernel/ns_container.c | 99 ++++++++++++++++++++++++++++++++++++++ > kernel/nsproxy.c | 16 ++++++ > 8 files changed, 183 insertions(+), 9 deletions(-) > create mode 100644 kernel/ns_container.c > > diff --git a/include/linux/container.h b/include/linux/container.h > index 37c0bdf..2f8ee47 100644 > --- a/include/linux/container.h > +++ b/include/linux/container.h > @@ -87,6 +87,8 @@ struct container { > /* Private poin…
creator: Pavel Emelianov
date: 2007-06-05T09:57:59-00:00

Re: [PATCH 1/1] containers: implement nsproxy containers subsystem
type: item
description: Quoting Pavel Emelianov (xemul@openvz.org): > Serge E. Hallyn wrote: > >>From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001 > > From: Serge E. Hallyn <serue@us.ibm.com> > > Date: Mon, 4 Jun 2007 14:18:52 -0400 > > Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem > > > > When a task enters a new namespace via a clone() or unshare(), a new > > container is created and the task moves into it. This enables > > I have a design question. > > How the child that has a new namespace guesses what id > this namespace has in containers? parse /proc/$$/container So more likely the parent would have to grab the cloned pid of the child, parse /proc/$$/container, then rename the container. -serge
creator: serue
date: 2007-06-05T12:13:58-00:00

Re: [PATCH 1/1] containers: implement nsproxy containers subsystem
type: item
description: Serge E. Hallyn wrote: > Quoting Pavel Emelianov (xemul@openvz.org): >> Serge E. Hallyn wrote: >>> >From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001 >>> From: Serge E. Hallyn <serue@us.ibm.com> >>> Date: Mon, 4 Jun 2007 14:18:52 -0400 >>> Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem >>> >>> When a task enters a new namespace via a clone() or unshare(), a new >>> container is created and the task moves into it. This enables >> I have a design question. >> >> How the child that has a new namespace guesses what id >> this namespace has in containers? > > parse /proc/$$/container Ok. > So more likely the parent would have to grab the cloned pid of the > child, parse /proc/$$/container, then rename the container. Child can happen to die before this and we'll have an orphaned container. I mean, it will be deletable, but its name will be unknown. Maybe its better to get the containers id from the pid of new task? > -serge > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ >
creator: Pavel Emelianov
date: 2007-06-05T13:04:58-00:00

Re: [PATCH 1/1] containers: implement nsproxy containers subsystem
type: item
description: Quoting Pavel Emelianov (xemul@openvz.org): > Serge E. Hallyn wrote: > > Quoting Pavel Emelianov (xemul@openvz.org): > >> Serge E. Hallyn wrote: > >>> >From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001 > >>> From: Serge E. Hallyn <serue@us.ibm.com> > >>> Date: Mon, 4 Jun 2007 14:18:52 -0400 > >>> Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem > >>> > >>> When a task enters a new namespace via a clone() or unshare(), a new > >>> container is created and the task moves into it. This enables > >> I have a design question. > >> > >> How the child that has a new namespace guesses what id > >> this namespace has in containers? > > > > parse /proc/$$/container > > Ok. > > > So more likely the parent would have to grab the cloned pid of the > > child, parse /proc/$$/container, then rename the container. > > Child can happen to die before this and we'll have an orphaned > container. I mean, it will be deletable, but its name will be unknown. Can we address that with a release_agent? Or, the program which did the unshare() (or the fn which was cloned()) can print out it's /proc/getpid()/container before it (optionally resets stdout and) executes the actual program to be run in the container. > Maybe its better to get the containers id from the pid of new task? Hmm, that seems reasonable. In fact I like it. Good idea, thanks. I think I'll go ahead and implement that. -serge
creator: serue
date: 2007-06-05T13:16:55-00:00

Re: [PATCH 1/1] containers: implement nsproxy containers subsystem
type: item
description: Quoting Pavel Emelianov (xemul@openvz.org): > Serge E. Hallyn wrote: > > Quoting Pavel Emelianov (xemul@openvz.org): > >> Serge E. Hallyn wrote: > >>> >From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001 > >>> From: Serge E. Hallyn <serue@us.ibm.com> > >>> Date: Mon, 4 Jun 2007 14:18:52 -0400 > >>> Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem > >>> > >>> When a task enters a new namespace via a clone() or unshare(), a new > >>> container is created and the task moves into it. This enables > >> I have a design question. > >> > >> How the child that has a new namespace guesses what id > >> this namespace has in containers? > > > > parse /proc/$$/container > > Ok. > > > So more likely the parent would have to grab the cloned pid of the > > child, parse /proc/$$/container, then rename the container. > > Child can happen to die before this and we'll have an orphaned > container. I mean, it will be deletable, but its name will be unknown. > > Maybe its better to get the containers id from the pid of new task? Here is a patch to do so: >From f42eeba62ec06544841070f55f6f1625c1216652 Mon Sep 17 00:00:00 2001 From: Serge E. Hallyn <serue@us.ibm.com> Date: Tue, 5 Jun 2007 10:25:05 -0400 Subject: [PATCH 1/1] containers: implement namespace tracking subsystem (v3) When a task enters a new namespace via a clone() or unshare(), a new container is created and the task moves into it. This version names containers which are automatically created using container_clone() as "node_<pid>" where pid is the pid of the unsharing or cloned process. (Thanks Pavel for the idea) This is safe because if the process unshares again, it will create /containers/(...)/node_<pid>/node_<pid> The only possibilities (AFAICT) for a -EEXIST on unshare are 1. pid wraparound 2. a process fails an unshare, then tries again. Case 1 is unlikely enough that I ignore it (at least for now). In case 2, the node_<pid> will be empty and can be rmdir'ed to make the subsequ…
creator: serue
date: 2007-06-06T01:27:43-00:00