On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: > >> Eric, >> >> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman >> <ebiederm@xxxxxxxxxxxx> wrote: >>> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: >>> >>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman >> <ebiederm@xxxxxxxxxxxx> wrote: >>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: >>>>> >>>>>> Hi Rob, >>>>>> >>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley <rob@xxxxxxxxxxx> >> wrote: >>>>>>> On 02/28/2013 05:24:07 AM, Michael Kerrisk (man-pages) wrote: >> [...] >>>>>>>> Because the above unshare(2) and setns(2) calls only change the >>>>>>>> PID namespace for created children, the clone(2) calls neces‐ >>>>>>>> sarily put the new thread in a different PID namespace from the >>>>>>>> calling thread. >>>>>>> >>>>>>> >>>>>>> Um, no they don't. They fail. That's the point. >>>>>> >>>>>> (Good catch.) >>>>>> >>>>>>> They _would_ put the new >>>>>>> thread in a different PID namespace, which breaks the definition >> of threads. >>>>>>> >>>>>>> How about: >>>>>>> >>>>>>> The above unshare(2) and setns(2) calls change the PID namespace >> of >>>>>>> children created by subsequent clone(2) calls, which is >> incompatible >>>>>>> with CLONE_VM. >>>>>> >>>>>> I decided on: >>>>>> >>>>>> The point here is that unshare(2) and setns(2) change the PID >>>>>> namespace for created children but not for the calling process, >>>>>> while clone(2) CLONE_VM specifies the creation of a new thread >>>>>> in the same process. >>>>> >>>>> Can we make that "for all new tasks created" instead of "created >>>>> children" >>>>> >>>>> Othewise someone might expect CLONE_THREAD would work as you >>>>> CLONE_THREAD creates a thread and not a child... >>>> >>>> The term "task" is kernel-space talk that rarely appears in man >> pages, >>>> so I am reluctant to use it. >>> >>> With respect to clone and in this case I am not certain we can >> properly >>> describe what happens without talking about tasks. But it is worth >>> a try. >>> >>> >>>> How about this: >>>> >>>> The point here is that unshare(2) and setns(2) change the PID >>>> namespace for processes subsequently created by the caller, but >>>> not for the calling process, while clone(2) CLONE_VM specifies >>>> the creation of a new thread in the same process. >>> >>> Hmm. How about this. >>> >>> The point here is that unshare(2) and setns(2) change the PID >>> namespace that will be used by in all subsequent calls to clone >>> and fork by the caller, but not for the calling process, and >>> that all threads in a process must share the same PID >>> namespace. Which makes a subsequent clone(2) CLONE_VM >>> specify the creation of a new thread in the a different PID >>> namespace but in the same process which is impossible. >> >> I did a little tidying: >> >> The point here is that unshare(2) and setns(2) change the >> PID namespace that will be used in all subsequent calls >> to clone(2) and fork(2), but do not change the PID names‐ >> pace of the calling process. Because a subsequent >> clone(2) CLONE_VM would imply the creation of a new >> thread in a different PID namespace, the operation is not >> permitted. >> >> Okay? > > That seems reasonable. > > CLONE_THREAD might be better to talk about. The check is CLONE_VM > because it is easier and CLONE_THREAD implies CLONE_THREAD. > >> Having asked that, I realize that I'm still not quite comfortable with >> this text. I think the problem is really one of terminology. At the >> start of this passage in the page, there is the sentence: >> >> Every thread in a process must be in the >> same PID namespace. >> >> Can you define "thread" in this context? > > Most definitely a thread group created with CLONE_THREAD. It is pretty > ugly in just the old fashioned CLONE_VM case too, but that might be > legal. > > In a few cases I think the implementation overshoots and test for VM > sharing instead of thread group membership because VM sharing is easier > to test for, and we already have tests for that. So, in summary, the point is that CLONE_VM is being used as a proxy for CLONE_THREAD because the former is easier to test for, and CLONE_THREAD requires CLONE_VM, right? -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Author of "The Linux Programming Interface"; http://man7.org/tlpi/ -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
