Re: For review: pid_namespaces(7) man page

[Michael Kerrisk (man-pages)]

[Resending, since my mobile device turned things into HTML]

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?

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?

Thanks,

Michael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/