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 X-Spam-Level: X-Spam-Status: No, score=-2.3 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 794B8C4CECE for ; Mon, 14 Oct 2019 10:08:36 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 575A120873 for ; Mon, 14 Oct 2019 10:08:36 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731016AbfJNKIf (ORCPT ); Mon, 14 Oct 2019 06:08:35 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:33409 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730880AbfJNKIf (ORCPT ); Mon, 14 Oct 2019 06:08:35 -0400 Received: from [212.86.36.32] (helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iJxH8-000093-VJ; Mon, 14 Oct 2019 10:08:27 +0000 Date: Mon, 14 Oct 2019 12:08:26 +0200 From: Christian Brauner To: "Michael Kerrisk (man-pages)" Cc: Aleksa Sarai , Linux Kernel , Oleg Nesterov , Florian Weimer , "libc-alpha@sourceware.org" , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Shuah Khan , Andrew Morton , Michal Hocko , Elena Reshetova , Thomas Gleixner , Roman Gushchin , Andrea Arcangeli , Al Viro , "Dmitry V. Levin" , linux-kselftest@vger.kernel.org Subject: Re: [PATCH 1/2] clone3: add CLONE3_CLEAR_SIGHAND Message-ID: <20191014100824.sc4aqfktbn6go736@wittgenstein> References: <20191010133518.5420-1-christian.brauner@ubuntu.com> <20191011221208.5eglbazksfigliob@yavin.dot.cyphar.com> <20191012074840.4to7lh4zbt4wup74@wittgenstein> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kselftest-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kselftest@vger.kernel.org On Sat, Oct 12, 2019 at 01:46:54PM +0200, Michael Kerrisk (man-pages) wrote: > On 10/12/19 9:48 AM, Christian Brauner wrote: > > On Sat, Oct 12, 2019 at 08:53:34AM +0200, Michael Kerrisk (man-pages) wrote: > >> Hello Aleksa, > >> > >> On Sat, 12 Oct 2019 at 00:12, Aleksa Sarai wrote: > >>> > >>> On 2019-10-11, Michael Kerrisk wrote: > >>>> Why CLONE3_CLEAR_SIGHAND rather than just CLONE_CLEAR_SIGHAND? > > > > I don't care much how we name this apart from the "_CLEAR_SIGHAND" > > suffix. But see for a little rationale below. > > > >>> > >>> There are no more flag bits left for the classic clone()/clone2() (the > >>> last one was used up by CLONE_PIDFD) -- thus this flag is clone3()-only. > >> > >> Yes, I understand that. But, I'm not sure that the "3" in the prefix > >> is necessary. "CLONE_" still seems better to me. > >> > >> Consider this: sometime in the near future we will probably have time > >> namespaces. The new flag for those namespaces will only be usable with > >> clone3(). It should NOT be called CLONE3_NEWTIME, but rather > >> CLONE_NEWTIME (or similar), because that same flag will presumably > >> also be used in other APIs such as unshare() and setns(). (Hmm -- I > > > > There are some noteable differences though. CLONE_NEWTIME takes the > > CSIGNAL bit which is in the range of a 32bit integer and thus useable by > > unshare() too. The same does not hold for CLONE{3}_CLEAR_SIGHAND. You > > can't pass it to unshare(). unshare() also just deals with > > namespace-relevant stuff so CLONE{3}_CLEAR_SIGHAND doesn't make much > > sense there. > > Sure, but going forward there's very likely to be more CLONE flags > for whatever reason, and some will be usable just in clone3() > while others will be more widely used (in other APIs such as > unshare() and setns()). Using two different prefixes for these > flags (CLONE_/CLONE3_) would be just confusing. AFAICS, the CLONE3_ I do agree with that part. And as I said in my previous mail, I don't care about the prefix. > prefix really provides no advantage, but does have the potential to > cause confusion down the track for the aforementioned reasons. > (Furthermore... Shudder! What if there's a clone4() one day. I > know you might say: "won't happen, we got things right this time", > but API history suggests that "right" now not infrequently becomes > "oops" later.) I do recommend CLONE_ for all the flags... I do love your trust in our ability to design syscalls (//Cc Aleksa ;)). :) > > >> wonder if we are going to need a new unshare2() or some such...) > > > > We still have one 32bit bit left (CLONE_DETACHED) which we can't reuse > > with clone()/clone2() but we can reuse with clone3(). We can simply > > earmark it for namespace-related stuff and thus still have one bit left > > for unshare() before we have to go for unshare2() (If we have to go > > there at all since I'm not sure how much more namespaces we can come up > > with.). > > I'm sure there'll be more namespaces... Let's hope not. :) Anyway, no real reason to do unshare2() any time soon. :) Christian