Received: by 2002:a25:e7d8:0:0:0:0:0 with SMTP id e207csp567354ybh; Wed, 18 Mar 2020 05:14:02 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtwADrqUVgUXFQzmaSlsAjXAfGRD4Wenv43XdBQvhajydNlXtxLtiAsw5Uo6ogSiLiMPhhY X-Received: by 2002:a05:6830:153:: with SMTP id j19mr3378955otp.168.1584533642761; Wed, 18 Mar 2020 05:14:02 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584533642; cv=none; d=google.com; s=arc-20160816; b=Zavang0FbpiiMJPMNZcUc5/rFATPYu7v/+j7ijN5Tf6mgBQXh5kzbi6Et9pc1uelac BixRpn9kekNHXFrhJ+cOCM3ITobFyHyI++WJ88LbG5QS/h9//H4c467v1bJhzpTjDnrC sSpfSRcl/Mne6n60yZDE4LmfKztPsSC8BeHwTO59KtMnoZApurBBR3uqVYjYiIDS84vX 5kQKkibvVU1hp6O2tEWeefkAYviyTc5dz6Fn+hmGxcxmOhHBVXN4z3K4PjxB7gOeZs80 DPQV8PAvVgK0WcYUqe9eyACyW9i1+vTJFlBHlEexsrR5wNFwIBii3YZPBGFxZqUHKifI QhPQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=n8K5I5zYPQClngwN1p4ujagbcpAT1Nyxl+k/aSoDhnE=; b=yXOyOAd7chCaBKZejzHwWXhIPFAvFtvULAk1i7S7hQyEJepfCFlZCaODjRw/NeeN5b ptp0NIl/4MMFDy+eEmDSkEwL4Xu6XqIFYguktQ9fKA2reIhgyOtpYeTUrzCYd1tF2Jto +aPcITZox+bP+VtV8Hnrbvj0+p6j1cnUGa5n6tEAqjHQUSuj/dIlODb+rp3CUnr7dVpL bKsX4Up/aRrCbqFA+nEkdcJ5JKRKrttTfPspE5/4AZODaQ6OCN3Kh0zmLEoyxDCNhgVQ iwRx9fH+wQOATAr2cwLF16Ren0PsjkIVPEAp83CCuOwgAG0DcXeBzf/TyZzMUHaQYGJy LKQA== 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 e19si3341384oti.20.2020.03.18.05.13.48; Wed, 18 Mar 2020 05:14:02 -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 S1726767AbgCRMNb (ORCPT + 99 others); Wed, 18 Mar 2020 08:13:31 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:36359 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726638AbgCRMNa (ORCPT ); Wed, 18 Mar 2020 08:13:30 -0400 Received: from ip5f5bf7ec.dynamic.kabel-deutschland.de ([95.91.247.236] helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.86_2) (envelope-from ) id 1jEXZW-0001wI-9u; Wed, 18 Mar 2020 12:13:18 +0000 Date: Wed, 18 Mar 2020 13:13:17 +0100 From: Christian Brauner To: Adrian Reber Cc: Eric Biederman , Pavel Emelyanov , Oleg Nesterov , Dmitry Safonov <0x7f454c46@gmail.com>, Andrei Vagin , linux-kernel@vger.kernel.org, Mike Rapoport , Radostin Stoyanov , Michael Kerrisk , Arnd Bergmann , Cyrill Gorcunov , Thomas Gleixner Subject: Re: [PATCH 2/4] clone3: allow creation of time namespace with offset Message-ID: <20200318121317.2vyfyqj223sx5ybq@wittgenstein> References: <20200317083043.226593-1-areber@redhat.com> <20200317083043.226593-3-areber@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200317083043.226593-3-areber@redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 17, 2020 at 09:30:42AM +0100, Adrian Reber wrote: > This extends clone3() to support the time namespace via CLONE_NEWTIME. > In addition to creating a new process in a new time namespace this > allows setting the clock offset in the newly created time namspace. > > The time namespace allows to set an offset for two clocks. > CLOCK_MONOTONIC and CLOCK_BOOTTIME. > > This clone3() extension also offers setting both offsets through the > newly introduced clone_args members timens_offset and > timens_offset_size. > > timens_offset: Pointer to an array of clock offsets for the > newly created process in a time namespaces. > This requires that a new time namespace has been > requested via CLONE_NEWTIME. It is only possible > to set an offset for CLOCK_MONOTONIC and > CLOCK_BOOTTIME. The array can therefore never > have more than two elements. > clone3() expects the array to contain the > following struct: > struct set_timens_offset { > int clockid; > struct timespec val; > }; > > timens_offset_size: This defines the size of the array referenced > in timens_offset. Currently this is limited > to two elements. > > To create a new process using clone3() in a new time namespace with > clock offsets, something like this can be used: > > struct set_timens_offset timens_offset[2]; > > timens_offset[0].clockid = CLOCK_BOOTTIME; > timens_offset[0].val.tv_sec = -1000; > timens_offset[0].val.tv_nsec = 42; > timens_offset[1].clockid = CLOCK_MONOTONIC; > timens_offset[1].val.tv_sec = 1000000; > timens_offset[1].val.tv_nsec = 37; > > struct _clone_args args = { > .flags = CLONE_NEWTIME, > .timens_offset = ptr_to_u64(timens_offset), > .timens_offset_size = 2; > }; In all honesty, this would be a terrible API and I think we need to come up with something better than this. I don't want to pass down an array of structs and in general would like to avoid this array + size pattern. That pattern kinda made sense for the pid array because of pid namespaces being nested but not for this case, I think. Also, why require the additional clockid argument here? That makes sense for clock_settime() and clock_gettime() but here we could just do: struct timens { struct timespec clock_bootime; struct timespec clock_monotonic; }; no? And since you need to expose that struct in a header somewhere anyway you can version it by size just like clone_args. So the kernel can apply the same pattern to be backwards compatible that we have with struct clone_args and for openat2()'s struct open_how via copy_struct_from_user. Then you only need one additional pointer in struct clone_args. What do we think? Christian