Received: by 2002:a5b:505:0:0:0:0:0 with SMTP id o5csp1940219ybp; Sat, 12 Oct 2019 00:49:18 -0700 (PDT) X-Google-Smtp-Source: APXvYqxWtf9mZhHofHDQtHjAwppjFcVmB0cre31pZZdF6z3Fl3l+tEKYbSV0sll8+kILgjnXoN3b X-Received: by 2002:aa7:d898:: with SMTP id u24mr8861725edq.74.1570866557983; Sat, 12 Oct 2019 00:49:17 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1570866557; cv=none; d=google.com; s=arc-20160816; b=sYxWBWzyUMdIg0YWkFO/8PO5Eot2DhkP8XRVqT5UbD18Q2thz5miRf1D5+lMbMB+gd wCwV8y8evhO/XdLOroYZZtjwLr56R2UQ3hMMWpyBPfa7oprgIg7/Y2nBypo39lVN6MiP nO11C2hX474+f0tB4Dg9liiKv2a6/RE0yCtHrGoB/gDq7ZR4ukOeoMCcfL1N/ieMf34E gv9hAktHLjDZgSgzwDzTo9Vf4Ws37VntPelyiXnTqo/NjXS4vNuFzhJPJ7rk2aDScuXr HztrhKIJMIro7cus0mfm14vfaM+N18FIQkzdO9R/y/xqaXDmP5Ss2tQa77yZc2LI7/Co M78A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=hHTDTolTaSl4ik97T1BPxLbdmonFgqZJgOehrzmo76Q=; b=a4KQwv51u2lhghr3xNvAZKSgKvjahdqNEiiIGRqjHF4+/wMqcox+lZ/+fh1Qj1+Sc6 0E9HWFc/ErcPrqhkky/1YQ5u6MLWsEpXwK8kZ9eGzZsD6ntfV168Musc+QVhXpG6Y9JD pDXzj/7f2tr++aOgBlzeNJJXuf2MfAQ/frhy6MvyZHSGQsBzxSHfnL7bTOnEIcTviSyy B3eIMqExtOS0WYBPRGPNUhvAL61PbOp83T7Vehe61Hmmbe39lwX5IXTBIxwaknGkvLQh A+76KlU/8fcDiR5OJy+hEB6HUxAATNSy9XbYgxwRsvp1+XN2btfpxjDMI4tbSWq12ub4 jAmw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l21si7847534edc.112.2019.10.12.00.48.52; Sat, 12 Oct 2019 00:49:17 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728821AbfJLHst (ORCPT + 99 others); Sat, 12 Oct 2019 03:48:49 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:48142 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726728AbfJLHst (ORCPT ); Sat, 12 Oct 2019 03:48:49 -0400 Received: from [213.220.153.21] (helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1iJC8p-00051r-DP; Sat, 12 Oct 2019 07:48:43 +0000 Date: Sat, 12 Oct 2019 09:48:42 +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: <20191012074840.4to7lh4zbt4wup74@wittgenstein> References: <20191010133518.5420-1-christian.brauner@ubuntu.com> <20191011221208.5eglbazksfigliob@yavin.dot.cyphar.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > 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.). Christian