From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman) Subject: Re: For review: pid_namespaces(7) man page Date: Tue, 05 Mar 2013 18:23:57 -0800 Message-ID: <87k3pl2rlu.fsf@xmission.com> References: <1362535117.7276.6@driftwood> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1362535117.7276.6@driftwood> (Rob Landley's message of "Tue, 05 Mar 2013 19:58:37 -0600") List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Rob Landley Cc: linux-man , Linux Containers , mtk.manpages-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org, lkml List-Id: containers.vger.kernel.org Rob Landley writes: > On 03/04/2013 11:52:19 AM, Eric W. Biederman wrote: >> > 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. > > CLONE_VM and CLONE_NEWPID are incompatible because all threads of the > same process must be in the same PID namespace. Since unshare(2) and > setns(2) change the PID namespace for subsequent calls to clone(2), > those subsequent calls cannot create new threads (unless you setns(2) > back to the original namespace first). > > That last bit's a guess. :) Good wording thank you, and the last bit is right. You can restore the pid namespace with setns(2), and that will allow thread and process creation creation again. Eric From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752371Ab3CFCYJ (ORCPT ); Tue, 5 Mar 2013 21:24:09 -0500 Received: from out03.mta.xmission.com ([166.70.13.233]:33906 "EHLO out03.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750858Ab3CFCYF (ORCPT ); Tue, 5 Mar 2013 21:24:05 -0500 From: ebiederm@xmission.com (Eric W. Biederman) To: Rob Landley Cc: mtk.manpages@gmail.com, linux-man , Linux Containers , lkml References: <1362535117.7276.6@driftwood> Date: Tue, 05 Mar 2013 18:23:57 -0800 In-Reply-To: <1362535117.7276.6@driftwood> (Rob Landley's message of "Tue, 05 Mar 2013 19:58:37 -0600") Message-ID: <87k3pl2rlu.fsf@xmission.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-AID: U2FsdGVkX192/u+rRHpG2FgvuPttmrvPRk1QmUBnsVI= X-SA-Exim-Connect-IP: 98.207.153.68 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 1.5 TR_Symld_Words too many words that have symbols inside * 0.0 T_TM2_M_HEADER_IN_MSG BODY: T_TM2_M_HEADER_IN_MSG * -3.0 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa01 1397; Body=1 Fuz1=1 Fuz2=1] * 0.0 T_XMDrugObfuBody_08 obfuscated drug references * 0.1 XMSolicitRefs_0 Weightloss drug X-Spam-DCC: XMission; sa01 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Rob Landley X-Spam-Relay-Country: Subject: Re: For review: pid_namespaces(7) man page X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Wed, 14 Nov 2012 14:26:46 -0700) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Rob Landley writes: > On 03/04/2013 11:52:19 AM, Eric W. Biederman wrote: >> > 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. > > CLONE_VM and CLONE_NEWPID are incompatible because all threads of the > same process must be in the same PID namespace. Since unshare(2) and > setns(2) change the PID namespace for subsequent calls to clone(2), > those subsequent calls cannot create new threads (unless you setns(2) > back to the original namespace first). > > That last bit's a guess. :) Good wording thank you, and the last bit is right. You can restore the pid namespace with setns(2), and that will allow thread and process creation creation again. Eric