From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 706CAEB64DD for ; Sun, 13 Aug 2023 13:35:32 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229451AbjHMNf2 (ORCPT ); Sun, 13 Aug 2023 09:35:28 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57748 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbjHMNf2 (ORCPT ); Sun, 13 Aug 2023 09:35:28 -0400 Received: from mail.hallyn.com (mail.hallyn.com [178.63.66.53]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5E7C41713 for ; Sun, 13 Aug 2023 06:35:29 -0700 (PDT) Received: by mail.hallyn.com (Postfix, from userid 1001) id 8B452A38; Sun, 13 Aug 2023 08:35:27 -0500 (CDT) Date: Sun, 13 Aug 2023 08:35:27 -0500 From: "Serge E. Hallyn" To: Alejandro Colomar Cc: linux-man@vger.kernel.org, Sargun Dhillon , Serge Hallyn , John Watts Subject: Re: [PATCH v2] clone.2: Fix outdated statement about CLONE_NEWPID Message-ID: <20230813133527.GA1148081@mail.hallyn.com> References: <20230813131727.35849-1-alx@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20230813131727.35849-1-alx@kernel.org> Precedence: bulk List-ID: X-Mailing-List: linux-man@vger.kernel.org On Sun, Aug 13, 2023 at 03:17:27PM +0200, Alejandro Colomar wrote: > From: Sargun Dhillon > > [TO += Serge] > > Hi Sargun, Serge! > > Sargun, I've slightly changed your patch, to keep the historical > information that in old versions of Linux this restriction was in place. > I also cleaned up the example program a little bit, and fixed the > formatting mistake I mentioned. See scissor patch below. > > However, reading the Linux commit that changed this, I had some doubts. > I've added Serge, in case he can remember the details. > > Serge, I see that the commit message for (Linux) 1f7f4dde5c94 quotes > some email of yours, and mentions that the commit fixes a regression. > So my doubt is: was this restriction in place before v3.13 as a stable > thing, or was it only accidentally introduced temporarily and soon > fixed? How should we document it? > > Cheers, > Alex > > ---8<----- > > It appears like the documentation is based on out of date information in > regards to using CLONE_NEWPID and CLONE_PARENT together. Since Linux > v3.13, this restriction has been lifted. See commit 1f7f4dde5c94 > ("fork: Allow CLONE_PARENT after setns(CLONE_NEWPID)"). > > For example, in this test program, one can see that it works: > > #include > #include > #include > #include > #include > #include > #include > #include > > static pid_t sys_clone3(struct clone_args *args); > > int > main(void) > { > int ret; > struct clone_args args = { > .flags = CLONE_PARENT | CLONE_NEWPID, > }; > > printf("main program: pid: %d, and ppid: %d\n", getpid(), getppid()); > > ret = sys_clone3(&args); > switch (ret) { > case -1: > err(EXIT_FAILURE, "clone3"); > case 0: > printf("child: pid: %d, and ppid: %d\n", getpid(), getppid()); > exit(EXIT_SUCCESS); > default: > exit(EXIT_SUCCESS); > } > } > > static pid_t > sys_clone3(struct clone_args *args) > { > fflush(stdout); > fflush(stderr); > return syscall(SYS_clone3, args, sizeof(*args)); > } > > This test program (successfully) outputs: > > # ./a.out > main program: pid: 34663, and ppid: 34662 > child: pid: 1, and ppid: 0 > > Cowritten-by: Sargun Dhillon > Cc: Serge Hallyn > Cc: John Watts > Signed-off-by: Alejandro Colomar > --- > > man2/clone.2 | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) > > diff --git a/man2/clone.2 b/man2/clone.2 > index b91b71831..225fef86d 100644 > --- a/man2/clone.2 > +++ b/man2/clone.2 > @@ -736,9 +736,11 @@ .SS The flags mask > can employ > .BR CLONE_NEWPID . > This flag can't be specified in conjunction with > -.B CLONE_THREAD > -or > -.BR CLONE_PARENT . > +.BR CLONE_THREAD . > +Before Linux 3.13, > +this flag couldn't be specified in conjunction with > +.B CLONE_PARENT Well no, I don't think that's right. That implies that the CLONE_PARENT check was a long standing one. In fact, the point was that it was a regression introduced in 40a0d32d1 (Wed Sep 11 14:19:41 2013 -0700) and then fixed in 1f7f4dde5 two months later. > +either. > .TP > .B CLONE_NEWUSER > (This flag first became meaningful for > -- > 2.40.1