Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754910Ab3CEIh2 (ORCPT ); Tue, 5 Mar 2013 03:37:28 -0500 Received: from mail-pb0-f43.google.com ([209.85.160.43]:61183 "EHLO mail-pb0-f43.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752851Ab3CEIh0 convert rfc822-to-8bit (ORCPT ); Tue, 5 Mar 2013 03:37:26 -0500 MIME-Version: 1.0 Reply-To: mtk.manpages@gmail.com In-Reply-To: <87r4jucprp.fsf@xmission.com> References: <1362110504.15531.4@driftwood> <87wqtr3zg5.fsf@xmission.com> <87k3pnhx2k.fsf@xmission.com> <87r4jucprp.fsf@xmission.com> From: "Michael Kerrisk (man-pages)" Date: Tue, 5 Mar 2013 09:37:05 +0100 Message-ID: Subject: Re: For review: pid_namespaces(7) man page To: "Eric W. Biederman" Cc: Rob Landley , linux-man , Linux Containers , lkml Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4710 Lines: 128 On Tue, Mar 5, 2013 at 7:41 AM, Eric W. Biederman wrote: > "Michael Kerrisk (man-pages)" writes: > >> Eric, >> >> On Mon, Mar 4, 2013 at 6:52 PM, Eric W. Biederman >> wrote: >>> "Michael Kerrisk (man-pages)" writes: >>> >>>> On Fri, Mar 1, 2013 at 4:35 PM, Eric W. Biederman >> wrote: >>>>> "Michael Kerrisk (man-pages)" writes: >>>>> >>>>>> Hi Rob, >>>>>> >>>>>> On Fri, Mar 1, 2013 at 5:01 AM, Rob Landley >> 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-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/