Quoting Eric W. Biederman (ebied...@xmission.com): > Oleg Nesterov <o...@redhat.com> writes: > > > Hi Serge, > > > > On 11/06, Serge Hallyn wrote: > >> > >> Hi Oleg, > >> > >> commit 40a0d32d1eaffe6aac7324ca92604b6b3977eb0e : > >> "fork: unify and tighten up CLONE_NEWUSER/CLONE_NEWPID checks" > >> breaks lxc-attach in 3.12. That code forks a child which does > >> setns() and then does a clone(CLONE_PARENT). That way the > >> grandchild can be in the right namespaces (which the child was > >> not) and be a child of the original task, which is the monitor. > > Serge that is a clever trick to get around the limitation that we can > not change the pid namespace of our current process. Given the > challenging relaying of signals etc I can see why you would use this. > > At the same time it makes me a little sad to see new users of > CLONE_PARENT. With CLONE_THREAD in existence the original reasons for > CLONE_PARENT are gone now. > > Having used bash as an init process I know it can handle unexpeted > children. However using CLONE_PARENT in this way still seems a little > dodgy. Or am I misunderstanding why you are using CLONE_PARENT?
FWIW Christian (cc:d from the start) was the author of that code, so he can correct me if i mis-speak, but IIUC the design is: 1. pid X is the first process running lxc-attach. It will be a monitor for the process which is entered into the container 2. pid X forks pid Y, which does setns(). Now if it is setns()ing into a pidns, it won't itself be in the new pidns, which is not satisfactory. So 3. pid Y clones pid Z with CLONE_PARENT. Y exists. Z continues, as a full member of the container, and a child of the monitor process. So yes, as you said it's exactly to work around the fact that pid Y can't change its own pidns. -serge ------------------------------------------------------------------------------ November Webinars for C, C++, Fortran Developers Accelerate application performance with scalable programming models. Explore techniques for threading, error checking, porting, and tuning. Get the most from the latest Intel processors and coprocessors. See abstracts and register http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
