Messages in this thread | | | Date | Wed, 15 Jan 2014 22:46:22 -0600 | From | Serge Hallyn <> | Subject | Re: CLONE_PARENT after setns(CLONE_NEWPID) |
| |
Quoting Christian Seiler (christian@iwakd.de): > Eric W. Biederman writes: > >So hmm. > > > >Because it can do no harm, and because it is a regression let's remove > >the CLONE_PARENT check and send it stable. > > > >diff --git a/kernel/fork.c b/kernel/fork.c > >index 086fe73..c447fbc 100644 > >--- a/kernel/fork.c > >+++ b/kernel/fork.c > >@@ -1174,7 +1174,7 @@ static struct task_struct *copy_process(unsigned long clone_flags, > > * do not allow it to share a thread group or signal handlers or > > * parent with the forking task. > > */ > >- if (clone_flags & (CLONE_SIGHAND | CLONE_PARENT)) { > >+ if (clone_flags & (CLONE_SIGHAND)) { > > if ((clone_flags & (CLONE_NEWUSER | CLONE_NEWPID)) || > > (task_active_pid_ns(current) != > > current->nsproxy->pid_ns_for_children)) > > Just a short question, what happened to this patch? As far as I can > tell, 3.13rc8 doesn't include it, neither does the current 3.12.7. This > means that lxc-attach currently still doesn't work on 3.12 and probably > won't work on 3.13 either... (3.11 is fine, see the previous mails in > this thread.)
So, hm. I didn't realize it hadn't hit upstream, because it's in the ubuntu kernel (unfortunately wrongly attributed).
However it is in linux-next since Nov 27.
-serge
| |