OpenVZ Forum - RDF feed
type: channel
items: [PATCH] allow a task to join a pid namespace
items: Re: [PATCH] allow a task to join a pid namespace
items: Re: Re: [PATCH] allow a task to join a pid namespace

[PATCH] allow a task to join a pid namespace
type: item
description: Currently, it is possible for a process to join existing net, uts and ipc namespaces. This patch allows a process to join an existing pid namespace as well. For that to remain sane, some restrictions are made in the calling process: * It needs to be in the parent namespace of the namespace it wants to jump to * It needs to sit in its own session and group as a leader. The rationale for that, is that people want to trigger actions in a Container from the outside. For instance, mainstream linux recently gained the ability to safely reboot a container. It would be desirable, however, that this action is triggered from an admin in the outside world, very much like a power switch in a physical box. This would also allow us to connect a console to the container, provide a repair mode for setups without networking (or with a broken one), etc. Signed-off-by: Glauber Costa <glommer@parallels.com> CC: Serge Hallyn <serge.hallyn@canonical.com> CC: Oleg Nesterov <oleg@redhat.com> CC: Michael Kerrisk <mtk.manpages@gmail.com> CC: "Eric W. Biederman" <ebiederm@xmission.com> CC: Tejun Heo <tj@kernel.org> CC: Daniel Lezcano <daniel.lezcano@linaro.org> --- fs/proc/namespaces.c | 3 ++ include/linux/proc_fs.h | 1 + kernel/pid_namespace.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 80 insertions(+) diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c index 0d9e23a..6b52af5 100644 --- a/fs/proc/namespaces.c +++ b/fs/proc/namespaces.c @@ -24,6 +24,9 @@ static const struct proc_ns_operations *ns_entries[] = { #ifdef CONFIG_IPC_NS &ipcns_operations, #endif +#ifdef CONFIG_PID_NS + &pidns_operations, +#endif }; static const struct file_operations ns_file_operations = { diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h index 3fd2e87..acaafcd 100644 --- a/include/linux/proc_fs.h +++ b/include/linux/proc_fs.h @@ -251,6 +251,7 @@ struct proc_ns_operations { extern const struct proc_ns_operations netns_operations; extern const struct proc_ns_operations ut…
creator: Glauber Costa
date: 2012-06-04T13:33:48-00:00

Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/04, Glauber Costa wrote: > > Currently, it is possible for a process to join existing > net, uts and ipc namespaces. This patch allows a process to join an > existing pid namespace as well. I can't understand this patch... but probably I missed something, I never really understood setns. > +static int pidns_install(struct nsproxy *nsproxy, void *_ns) > +{ > + struct pid *newpid; > + struct pid_namespace *ns = _ns; > + > + if (is_container_init(current)) > + return -EINVAL; > + > + if (nsproxy->pid_ns != ns->parent) > + return -EPERM; At least you should also check that current is single-threaded, I guess. > + > + if (task_pgrp(current) != task_pid(current)) > + return -EPERM; > + > + if (task_session(current) != task_pid(current)) > + return -EPERM; Both checks are obviously racy without tasklist. > + newpid = alloc_pid(ns); > + if (!newpid) > + return -ENOMEM; Hmm. Doesn't this mean that pid_nr of this task (as it seen in its current namespace) will be changed? This doesn't look sane. > + put_pid_ns(nsproxy->pid_ns); > + nsproxy->pid_ns = get_pid_ns(ns); > + > + write_lock_irq(&tasklist_lock); > + change_pid(current, PIDTYPE_PID, newpid); > + change_pid(current, PIDTYPE_PGID, newpid); > + change_pid(current, PIDTYPE_SID, newpid); > + write_unlock_irq(&tasklist_lock); Hmm. So, until the caller does switch_task_namespaces() task_active_pid_ns(current) != current->nsproxy->pid_ns, doesn't look very nice too. I don't think this can be right. If nothing else, this breaks it_real_fn(). Oleg.
creator: Oleg Nesterov
date: 2012-06-04T16:51:17-00:00

Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/04/2012 06:51 PM, Oleg Nesterov wrote: > On 06/04, Glauber Costa wrote: >> >> Currently, it is possible for a process to join existing >> net, uts and ipc namespaces. This patch allows a process to join an >> existing pid namespace as well. > > I can't understand this patch... but probably I missed something, > I never really understood setns. Hi Oleg, let me clarify why is needed setns. In the world of container, setns allows to administrate the container from outside. One good example is to shutdown the container. The users setup their hosts with the init's services to startup the containers when the system starts, but they have no way to invoke 'shutdown' from inside the container when the system goes down except doing some trick with the signals. The setns syscall with the pid namespace support will allow to do that. Also a complete setns support will allow to write some administrative tools to have a global view of the different separated resources running in several containers. For example, if you are the administrator of the host and you have hundred of containers running on it, you can use setns to run netstat within each container and build a view of the different network stack. The same applies for 'ps' or 'top'. Without setns, things are much more complicated and in some cases, impossible. For instance, you can run a daemon inside the container, send command to it and redirect its output to the fifo but that increase the number of processes and has some limitations. Also that means the command you want to run is present in the container's FS. The setns syscall is highly needed for the VRF, where a single process can handle thousand of network namespaces and switch from a network namespace to another network namespace with one syscall. The usage of the file descriptors pins the namespace and prevent it from being destroyed when switching from one namespace to another. In other words, +1 for pid ns support with setns :) -- Daniel
creator: Daniel Lezcano
date: 2012-06-05T09:30:08-00:00

Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/04/2012 03:33 PM, Glauber Costa wrote: > Currently, it is possible for a process to join existing > net, uts and ipc namespaces. This patch allows a process to join an > existing pid namespace as well. > > For that to remain sane, some restrictions are made in the calling process: > > * It needs to be in the parent namespace of the namespace it wants to jump to > * It needs to sit in its own session and group as a leader. > > The rationale for that, is that people want to trigger actions in a Container > from the outside. For instance, mainstream linux recently gained the ability > to safely reboot a container. It would be desirable, however, that this > action is triggered from an admin in the outside world, very much like a > power switch in a physical box. > > This would also allow us to connect a console to the container, provide a > repair mode for setups without networking (or with a broken one), etc. Hi Glauber, I am in favor of this patch but I think the pidns support won't be complete and some corner-cases are not handled. May be you can look at Eric's patchset [1] where, IMO, everything is taken into account. Some of the patches may be already upstream. Thanks -- Daniel [1] http://git.kernel.org/?p=linux/kernel/git/ebiederm/linux-nam espace-control-devel.git;a=summary
creator: Daniel Lezcano
date: 2012-06-05T09:36:21-00:00

Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/05/2012 01:36 PM, Daniel Lezcano wrote: > On 06/04/2012 03:33 PM, Glauber Costa wrote: >> Currently, it is possible for a process to join existing >> net, uts and ipc namespaces. This patch allows a process to join an >> existing pid namespace as well. >> >> For that to remain sane, some restrictions are made in the calling process: >> >> * It needs to be in the parent namespace of the namespace it wants to jump to >> * It needs to sit in its own session and group as a leader. >> >> The rationale for that, is that people want to trigger actions in a Container >> from the outside. For instance, mainstream linux recently gained the ability >> to safely reboot a container. It would be desirable, however, that this >> action is triggered from an admin in the outside world, very much like a >> power switch in a physical box. >> >> This would also allow us to connect a console to the container, provide a >> repair mode for setups without networking (or with a broken one), etc. > > Hi Glauber, > > I am in favor of this patch but I think the pidns support won't be > complete and some corner-cases are not handled. > > May be you can look at Eric's patchset [1] where, IMO, everything is > taken into account. Some of the patches may be already upstream. > > Thanks > -- Daniel I don't remember seeing such patchset in the mailing lists, but that might be my fault, due to traffic... I'll take a look. If it does what I need, I can just drop this. Thanks
creator: Glauber Costa
date: 2012-06-05T09:37:10-00:00

Re: Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/05/2012 01:37 PM, Glauber Costa wrote: > On 06/05/2012 01:36 PM, Daniel Lezcano wrote: >> On 06/04/2012 03:33 PM, Glauber Costa wrote: >>> Currently, it is possible for a process to join existing >>> net, uts and ipc namespaces. This patch allows a process to join an >>> existing pid namespace as well. >>> >>> For that to remain sane, some restrictions are made in the calling >>> process: >>> >>> * It needs to be in the parent namespace of the namespace it wants to >>> jump to >>> * It needs to sit in its own session and group as a leader. >>> >>> The rationale for that, is that people want to trigger actions in a >>> Container >>> from the outside. For instance, mainstream linux recently gained the >>> ability >>> to safely reboot a container. It would be desirable, however, that this >>> action is triggered from an admin in the outside world, very much like a >>> power switch in a physical box. >>> >>> This would also allow us to connect a console to the container, >>> provide a >>> repair mode for setups without networking (or with a broken one), etc. >> >> Hi Glauber, >> >> I am in favor of this patch but I think the pidns support won't be >> complete and some corner-cases are not handled. >> >> May be you can look at Eric's patchset [1] where, IMO, everything is >> taken into account. Some of the patches may be already upstream. >> >> Thanks >> -- Daniel > > I don't remember seeing such patchset in the mailing lists, but that > might be my fault, due to traffic... > > I'll take a look. If it does what I need, I can just drop this. > Ok. In a quick look, it does not seem to go all the way. This is just by reading, but your reboot patch, for instance, is unlikely to work with that, since if it doesn't alter pid->level, things like task ns_of_pid won't work. Running the test scripts I wrote for my testing of that patch also doesn't seem to produce the expected result: after doing setns, the pid won't show up in that namespace. But I can work on top of that t…
creator: Glauber Costa
date: 2012-06-05T10:00:00-00:00

Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/05/2012 01:36 PM, Daniel Lezcano wrote: > On 06/04/2012 03:33 PM, Glauber Costa wrote: >> Currently, it is possible for a process to join existing >> net, uts and ipc namespaces. This patch allows a process to join an >> existing pid namespace as well. >> >> For that to remain sane, some restrictions are made in the calling process: >> >> * It needs to be in the parent namespace of the namespace it wants to jump to >> * It needs to sit in its own session and group as a leader. >> >> The rationale for that, is that people want to trigger actions in a Container >> from the outside. For instance, mainstream linux recently gained the ability >> to safely reboot a container. It would be desirable, however, that this >> action is triggered from an admin in the outside world, very much like a >> power switch in a physical box. >> >> This would also allow us to connect a console to the container, provide a >> repair mode for setups without networking (or with a broken one), etc. > > Hi Glauber, > > I am in favor of this patch but I think the pidns support won't be > complete and some corner-cases are not handled. > > May be you can look at Eric's patchset [1] where, IMO, everything is > taken into account. Some of the patches may be already upstream. > > Thanks > -- Daniel > Daniel, Please let me know what you think of the attached patch. It is ontop of Eric's tree that you pointed me to, but I am not really using any of its functionality, so this would be equally doable in current mainline kernel - but I wanted to make sure it integrates well with what Eric is doing as well. It is a bit wasteful space-wise, but this approach pretty much guarantees we don't need to update pointers anywhere - therefore, totally lock-free. pid->level is only updated after switch_task_namespaces(), so every call before that will see correct information up to the previous level.
creator: Glauber Costa
date: 2012-06-05T11:33:34-00:00

Re: Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/05/2012 12:00 PM, Glauber Costa wrote: > On 06/05/2012 01:37 PM, Glauber Costa wrote: >> On 06/05/2012 01:36 PM, Daniel Lezcano wrote: >>> On 06/04/2012 03:33 PM, Glauber Costa wrote: >>>> Currently, it is possible for a process to join existing >>>> net, uts and ipc namespaces. This patch allows a process to join an >>>> existing pid namespace as well. >>>> >>>> For that to remain sane, some restrictions are made in the calling >>>> process: >>>> >>>> * It needs to be in the parent namespace of the namespace it wants to >>>> jump to >>>> * It needs to sit in its own session and group as a leader. >>>> >>>> The rationale for that, is that people want to trigger actions in a >>>> Container >>>> from the outside. For instance, mainstream linux recently gained the >>>> ability >>>> to safely reboot a container. It would be desirable, however, that >>>> this >>>> action is triggered from an admin in the outside world, very much >>>> like a >>>> power switch in a physical box. >>>> >>>> This would also allow us to connect a console to the container, >>>> provide a >>>> repair mode for setups without networking (or with a broken one), etc. >>> >>> Hi Glauber, >>> >>> I am in favor of this patch but I think the pidns support won't be >>> complete and some corner-cases are not handled. >>> >>> May be you can look at Eric's patchset [1] where, IMO, everything is >>> taken into account. Some of the patches may be already upstream. >>> >>> Thanks >>> -- Daniel >> >> I don't remember seeing such patchset in the mailing lists, but that >> might be my fault, due to traffic... >> >> I'll take a look. If it does what I need, I can just drop this. >> > > Ok. In a quick look, it does not seem to go all the way. This is just > by reading, but your reboot patch, for instance, is unlikely to work > with that, since if it doesn't alter pid->level, things like task > ns_of_pid won't work. > > Running the test scripts I wrote for my testing of that patch also > doesn't seem to produc…
creator: Daniel Lezcano
date: 2012-06-05T12:52:17-00:00

Re: Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/05/2012 04:52 PM, Daniel Lezcano wrote: > On 06/05/2012 12:00 PM, Glauber Costa wrote: >> On 06/05/2012 01:37 PM, Glauber Costa wrote: >>> On 06/05/2012 01:36 PM, Daniel Lezcano wrote: >>>> On 06/04/2012 03:33 PM, Glauber Costa wrote: >>>>> Currently, it is possible for a process to join existing >>>>> net, uts and ipc namespaces. This patch allows a process to join an >>>>> existing pid namespace as well. >>>>> >>>>> For that to remain sane, some restrictions are made in the calling >>>>> process: >>>>> >>>>> * It needs to be in the parent namespace of the namespace it wants to >>>>> jump to >>>>> * It needs to sit in its own session and group as a leader. >>>>> >>>>> The rationale for that, is that people want to trigger actions in a >>>>> Container >>>>> from the outside. For instance, mainstream linux recently gained the >>>>> ability >>>>> to safely reboot a container. It would be desirable, however, that >>>>> this >>>>> action is triggered from an admin in the outside world, very much >>>>> like a >>>>> power switch in a physical box. >>>>> >>>>> This would also allow us to connect a console to the container, >>>>> provide a >>>>> repair mode for setups without networking (or with a broken one), etc. >>>> >>>> Hi Glauber, >>>> >>>> I am in favor of this patch but I think the pidns support won't be >>>> complete and some corner-cases are not handled. >>>> >>>> May be you can look at Eric's patchset [1] where, IMO, everything is >>>> taken into account. Some of the patches may be already upstream. >>>> >>>> Thanks >>>> -- Daniel >>> >>> I don't remember seeing such patchset in the mailing lists, but that >>> might be my fault, due to traffic... >>> >>> I'll take a look. If it does what I need, I can just drop this. >>> >> >> Ok. In a quick look, it does not seem to go all the way. This is just >> by reading, but your reboot patch, for instance, is unlikely to work >> with that, since if it doesn't alter pid->level, things like task >> ns_of_pid won't work…
creator: Glauber Costa
date: 2012-06-05T12:53:43-00:00

Re: Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/05/2012 02:53 PM, Glauber Costa wrote: > On 06/05/2012 04:52 PM, Daniel Lezcano wrote: >> On 06/05/2012 12:00 PM, Glauber Costa wrote: >>> On 06/05/2012 01:37 PM, Glauber Costa wrote: >>>> On 06/05/2012 01:36 PM, Daniel Lezcano wrote: >>>>> On 06/04/2012 03:33 PM, Glauber Costa wrote: >>>>>> Currently, it is possible for a process to join existing >>>>>> net, uts and ipc namespaces. This patch allows a process to join an >>>>>> existing pid namespace as well. >>>>>> >>>>>> For that to remain sane, some restrictions are made in the calling >>>>>> process: >>>>>> >>>>>> * It needs to be in the parent namespace of the namespace it >>>>>> wants to >>>>>> jump to >>>>>> * It needs to sit in its own session and group as a leader. >>>>>> >>>>>> The rationale for that, is that people want to trigger actions in a >>>>>> Container >>>>>> from the outside. For instance, mainstream linux recently gained the >>>>>> ability >>>>>> to safely reboot a container. It would be desirable, however, that >>>>>> this >>>>>> action is triggered from an admin in the outside world, very much >>>>>> like a >>>>>> power switch in a physical box. >>>>>> >>>>>> This would also allow us to connect a console to the container, >>>>>> provide a >>>>>> repair mode for setups without networking (or with a broken one), >>>>>> etc. >>>>> >>>>> Hi Glauber, >>>>> >>>>> I am in favor of this patch but I think the pidns support won't be >>>>> complete and some corner-cases are not handled. >>>>> >>>>> May be you can look at Eric's patchset [1] where, IMO, everything is >>>>> taken into account. Some of the patches may be already upstream. >>>>> >>>>> Thanks >>>>> -- Daniel >>>> >>>> I don't remember seeing such patchset in the mailing lists, but that >>>> might be my fault, due to traffic... >>>> >>>> I'll take a look. If it does what I need, I can just drop this. >>>> >>> >>> Ok. In a quick look, it does not seem to go all the way. This is just >>> by reading, but your reboot patch, for instance, is …
creator: Daniel Lezcano
date: 2012-06-05T13:18:59-00:00

Re: [PATCH] allow a task to join a pid namespace
type: item
description: Glauber Costa <glommer@parallels.com> writes: > Currently, it is possible for a process to join existing > net, uts and ipc namespaces. This patch allows a process to join an > existing pid namespace as well. > > For that to remain sane, some restrictions are made in the calling process: > > * It needs to be in the parent namespace of the namespace it wants to jump to > * It needs to sit in its own session and group as a leader. > > The rationale for that, is that people want to trigger actions in a Container > from the outside. For instance, mainstream linux recently gained the ability > to safely reboot a container. It would be desirable, however, that this > action is triggered from an admin in the outside world, very much like a > power switch in a physical box. > > This would also allow us to connect a console to the container, provide a > repair mode for setups without networking (or with a broken one), etc. > > Signed-off-by: Glauber Costa <glommer@parallels.com> > CC: Serge Hallyn <serge.hallyn@canonical.com> > CC: Oleg Nesterov <oleg@redhat.com> > CC: Michael Kerrisk <mtk.manpages@gmail.com> > CC: "Eric W. Biederman" <ebiederm@xmission.com> > CC: Tejun Heo <tj@kernel.org> > CC: Daniel Lezcano <daniel.lezcano@linaro.org> > --- > fs/proc/namespaces.c | 3 ++ > include/linux/proc_fs.h | 1 + > kernel/pid_namespace.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++ > 3 files changed, 80 insertions(+) > > diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c > index 0d9e23a..6b52af5 100644 > --- a/fs/proc/namespaces.c > +++ b/fs/proc/namespaces.c > @@ -24,6 +24,9 @@ static const struct proc_ns_operations *ns_entries[] = { > #ifdef CONFIG_IPC_NS > &ipcns_operations, > #endif > +#ifdef CONFIG_PID_NS > + &pidns_operations, > +#endif > }; > > static const struct file_operations ns_file_operations = { > diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h > index 3fd2e87..acaafcd 100644 > --- a/include/linux/proc_fs.h > +++ b/include/linux/proc_fs.h > …
creator: ebiederm
date: 2012-06-05T16:49:33-00:00

Re: [PATCH] allow a task to join a pid namespace
type: item
description: Oleg Nesterov <oleg@redhat.com> writes: > On 06/04, Glauber Costa wrote: >> >> Currently, it is possible for a process to join existing >> net, uts and ipc namespaces. This patch allows a process to join an >> existing pid namespace as well. > > I can't understand this patch... but probably I missed something, > I never really understood setns. The idea with setns is akin to callusermodehelper in the kernel. >From outside a container we want to allow an appropriately privileged user to create a process inside the container. We run into all kinds of interesting gotchas with entering the pid namespace: - Disjoint process trees. - Ensuring all processes are gone when we exit a pid namespace. - Not letting an empty pid namespace accept more processes. We really only have two possbilities here. - Allocate a new struct pid that is a superset of our current struct pid but having additional processes ids inside a new pid namespace. Along with all of the appropriate sanity checks to make that safe. - Just modify the pid namespace the child processes of setns will use. I lean towards the second option as that seems to have the best semantic match to practical applications, and fewer kernel races to contend with, but I might be persuadable. However we do this we need to fix the bugs in pid namespace cleanup, and deal with the issues that disjoint process trees bring to waiting for all processes in a pid namespace to exit. Ugh. Getting the waking up of zap_pid_ns_processes right and handling the reaping of zombines in the cases of disjoint process trees is going to be interesting. Eric
creator: ebiederm
date: 2012-06-05T17:18:52-00:00

Re: Re: [PATCH] allow a task to join a pid namespace
type: item
description: > Eric, what are your plans for merging the content of that tree ? Hopefully this cycle. The issue with the pid namespace is primarily that we need to fix all of the life cycle issues with the pid namespace and make certain that setns adding an additional pid in a pid namespace does not break those pid namespace life cycle fixes. So I have been working on the hard tricky fixes off and on with Oleg. Eric
creator: ebiederm
date: 2012-06-05T17:39:09-00:00

Re: [PATCH] allow a task to join a pid namespace
type: item
description: On 06/05/2012 08:49 PM, Eric W. Biederman wrote: > Glauber Costa<glommer@parallels.com> writes: > >> Currently, it is possible for a process to join existing >> net, uts and ipc namespaces. This patch allows a process to join an >> existing pid namespace as well. >> >> For that to remain sane, some restrictions are made in the calling process: >> >> * It needs to be in the parent namespace of the namespace it wants to jump to >> * It needs to sit in its own session and group as a leader. >> >> The rationale for that, is that people want to trigger actions in a Container >> from the outside. For instance, mainstream linux recently gained the ability >> to safely reboot a container. It would be desirable, however, that this >> action is triggered from an admin in the outside world, very much like a >> power switch in a physical box. >> >> This would also allow us to connect a console to the container, provide a >> repair mode for setups without networking (or with a broken one), etc. >> >> Signed-off-by: Glauber Costa<glommer@parallels.com> >> CC: Serge Hallyn<serge.hallyn@canonical.com> >> CC: Oleg Nesterov<oleg@redhat.com> >> CC: Michael Kerrisk<mtk.manpages@gmail.com> >> CC: "Eric W. Biederman"<ebiederm@xmission.com> >> CC: Tejun Heo<tj@kernel.org> >> CC: Daniel Lezcano<daniel.lezcano@linaro.org> >> --- >> fs/proc/namespaces.c | 3 ++ >> include/linux/proc_fs.h | 1 + >> kernel/pid_namespace.c | 76 +++++++++++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 80 insertions(+) >> >> diff --git a/fs/proc/namespaces.c b/fs/proc/namespaces.c >> index 0d9e23a..6b52af5 100644 >> --- a/fs/proc/namespaces.c >> +++ b/fs/proc/namespaces.c >> @@ -24,6 +24,9 @@ static const struct proc_ns_operations *ns_entries[] = { >> #ifdef CONFIG_IPC_NS >> &ipcns_operations, >> #endif >> +#ifdef CONFIG_PID_NS >> + &pidns_operations, >> +#endif >> }; >> >> static const struct file_operations ns_file_operations = { >> diff --git a/include/linux/proc_fs.h b/include/linux/proc_fs.h >> inde…
creator: Glauber Costa
date: 2012-06-06T08:54:23-00:00

Re: [PATCH] allow a task to join a pid namespace
type: item
description: Glauber Costa <glommer@parallels.com> writes: > > Please let me know what you think of the attached patch. It is ontop of Eric's > tree that you pointed me to, but I am not really using any of its functionality, > so this would be equally doable in current mainline kernel - but I wanted to > make sure it integrates well with what Eric is doing as well. The trees I have out there for pid namespace work are for historical reference at this point. > It is a bit wasteful space-wise, but this approach pretty much guarantees we > don't need to update pointers anywhere - therefore, totally > lock-free. pid->level is only updated after switch_task_namespaces(), so every > call before that will see correct information up to the previous > level. This solves none of the pid namespace life cycle problems and the issues you solve by extending a pid can probably be solved better by allocating a new pid and setting it's low pids the same as the original pid and then atomically swapping them. So I do not find the patch below at all interesting. Eric > From 1192e0ff3c854f4690d44fadccbc575fff653578 Mon Sep 17 00:00:00 2001 > From: Glauber Costa <glommer@parallels.com> > Date: Tue, 5 Jun 2012 15:23:12 +0400 > Subject: [PATCH] pid_ns: expand the current pid namespace to a new namespace > > install pid_ns doesn't go as far as needed. Things like > ns_of_pid() will rely on the current level to get to the > right task. So when attaching a task to a new pid namespace, > we need to make sure the upid vector grows as needed, and the > level updated accordingly > > To do that, this patch leaves room for one more upid at the end > of the structure at all times. It also stores the original level so > we know afterwards which cache to free from. > > Although this is, of course, a bit wasteful, it has the advantage > that we never need to touch the existing struct pid, nor the existing > upid vectors. That would be racy in nature, and may require us to pick > locks here and there - which seems t…
creator: ebiederm
date: 2012-06-06T18:29:16-00:00