Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp513838ybb; Wed, 25 Mar 2020 04:28:41 -0700 (PDT) X-Google-Smtp-Source: ADFU+vvYBsXHO5GkN9dzDJQHg/bm/zz66ZrdcwWnHQ6iE15MaqTfEL7QtJIOJ63SSdOztYulb+Yv X-Received: by 2002:aca:d50f:: with SMTP id m15mr2203462oig.19.1585135720879; Wed, 25 Mar 2020 04:28:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1585135720; cv=none; d=google.com; s=arc-20160816; b=lIgNm94DaR+tj9pIcSw+CiJQEGWUnnxBgylnutJ03FD5SPJIToul3eg1dWF3xsFtcO 5ltvDHAyA/ZgRpgCKwJPcn/GjkE+o8Xaruo27WyxLq8I+9sC/9j2UazUqufu+UKTpXAS 50Wm4UC8azKpBNhZUDsTnKthFRYcnRMIPdgy4GUB6j1tw8IR460Jem76B6dCM9ZPlujW iMpn7UsLaJrX/Mdpw5kR1y2nUvRWWNVbMg+wlnr/8R/0pTRydKVzs4eva+PcGMhpo3xI gKx1p7+CK6KqgbPnOrM7jfbeVXLvtt9449hYxepmOJhZnJmxvcx9Bb5sv6o2o9zaVmuK wCFw== 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=TuZHEDYHr/3GMkHwcVpym9NaoXykzxEKa/2hB3gimVU=; b=JWzxN6ON6gfZun6G76/Q4UyQBeHORUX4dboiLMb930qTELRSUytrK7+JzEODO2dPK0 0rGSW6I7rJXxTZCp1p0604YQATPDhF3XdLncM3N3qTufnB2Fz6ETR0nXWYrc0Em/FKA1 PSEpLkVqY1RqdboaYu7SZBADHMAN1e4H4GUraXQwX2MkbaF1Qvn8jDogdR/AFAMrkkFy GvSDMEU3158r2cMnqtzMCQBarVghEoep/VNliRHj1o+S6lpkgMpYPdeWd+elOC3wznAO HZ+RK+7Vi/KUZ+hueiOwNpMRS+0RTq2DIulZsf25S33us2BtjufBQMGG5m4x3BbBCqo3 6LBg== 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 e24si2559979otq.2.2020.03.25.04.28.28; Wed, 25 Mar 2020 04:28:40 -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 S1727357AbgCYL1P (ORCPT + 99 others); Wed, 25 Mar 2020 07:27:15 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:51282 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726700AbgCYL1P (ORCPT ); Wed, 25 Mar 2020 07:27:15 -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 1jH4BR-0007uT-JQ; Wed, 25 Mar 2020 11:26:53 +0000 Date: Wed, 25 Mar 2020 12:26:52 +0100 From: Christian Brauner To: Adrian Reber Cc: Andrei Vagin , Arnd Bergmann , Eric Biederman , Pavel Emelyanov , Oleg Nesterov , Dmitry Safonov <0x7f454c46@gmail.com>, "linux-kernel@vger.kernel.org" , Mike Rapoport , Radostin Stoyanov , Michael Kerrisk , Cyrill Gorcunov , Thomas Gleixner , Aleksa Sarai , Linux API Subject: Re: clone3: allow creation of time namespace with offset Message-ID: <20200325112652.sx66bhad7cqdsatm@wittgenstein> References: <20200317083043.226593-1-areber@redhat.com> <20200319081137.GC223854@dcbz.redhat.com> <20200319102955.i7slokibkkysz6g6@wittgenstein> <20200320183355.GA118769@gmail.com> <20200324160945.orcm75avj2ol3eop@wittgenstein> <20200324162546.GG358599@dcbz.redhat.com> <20200324175649.fqkwiuvs2drk26ln@wittgenstein> <20200325075836.GK358599@dcbz.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200325075836.GK358599@dcbz.redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 25, 2020 at 08:58:36AM +0100, Adrian Reber wrote: > On Tue, Mar 24, 2020 at 06:56:49PM +0100, Christian Brauner wrote: > > On Tue, Mar 24, 2020 at 05:25:46PM +0100, Adrian Reber wrote: > > > On Tue, Mar 24, 2020 at 05:09:45PM +0100, Christian Brauner wrote: > > > > On Fri, Mar 20, 2020 at 11:33:55AM -0700, Andrei Vagin wrote: > > > > > On Thu, Mar 19, 2020 at 11:29:55AM +0100, Christian Brauner wrote: > > > > > > On Thu, Mar 19, 2020 at 09:16:43AM +0100, Arnd Bergmann wrote: > > > > > > > On Thu, Mar 19, 2020 at 9:11 AM Adrian Reber wrote: > > > > > > > > > > > > > > > With Arnd's idea of only using nanoseconds, timens_offset would then > > > > > > > > contain something like this: > > > > > > > > > > > > > > > > struct timens_offset { > > > > > > > > __aligned_s64 monotonic_offset_ns; > > > > > > > > __aligned_s64 boottime_offset_ns; > > > > > > > > }; > > > > > > > > > > > > > > > > I kind of prefer adding boottime and monotonic directly to struct clone_args > > > > > > > > > > > > > > > > __aligned_u64 tls; > > > > > > > > __aligned_u64 set_tid; > > > > > > > > __aligned_u64 set_tid_size; > > > > > > > > + __aligned_s64 monotonic_offset_ns; > > > > > > > > + __aligned_s64 boottime_offset_ns; > > > > > > > > }; > > > > > > > > > > > > > > I would also prefer the second approach using two 64-bit integers > > > > > > > instead of a pointer, as it keeps the interface simpler to implement > > > > > > > and simpler to interpret by other tools. > > > > > > > > > > > > Why I don't like has two reasons. There's the scenario where we have > > > > > > added new extensions after the new boottime member and then we introduce > > > > > > another offset. Then you'd be looking at: > > > > > > > > > > > > __aligned_u64 tls; > > > > > > __aligned_u64 set_tid; > > > > > > __aligned_u64 set_tid_size; > > > > > > + __aligned_s64 monotonic_offset_ns; > > > > > > + __aligned_s64 boottime_offset_ns; > > > > > > __aligned_s64 something_1 > > > > > > __aligned_s64 anything_2 > > > > > > + __aligned_s64 sometime_offset_ns > > > > > > > > > > > > which bothers me just by looking at it. That's in addition to adding two > > > > > > new members to the struct when most people will never set CLONE_NEWTIME. > > > > > > We'll also likely have more features in the future that will want to > > > > > > pass down more info than we want to directly expose in struct > > > > > > clone_args, e.g. for a long time I have been thinking about adding a > > > > > > struct for CLONE_NEWUSER that allows you to specify the id mappings you > > > > > > want the new user namespace to get. We surely don't want to force all > > > > > > new info into the uppermost struct. So I'm not convinced we should here. > > > > > > > > > > I think here we can start thinking about a netlink-like interface. > > > > > > > > I think netlink is just not a great model for an API and I would not > > > > want us to go down that route. > > > > > > > > I kept thinking about this for a bit and I think that we will end up > > > > growing more namespace-related functionality. So one thing that came to > > > > my mind is the following layout: > > > > > > > > struct { > > > > struct { > > > > __s64 monotonic; > > > > __s64 boot; > > > > } time; > > > > } namespaces; > > > > > > > > struct _clone_args { > > > > __aligned_u64 flags; > > > > __aligned_u64 pidfd; > > > > __aligned_u64 child_tid; > > > > __aligned_u64 parent_tid; > > > > __aligned_u64 exit_signal; > > > > __aligned_u64 stack; > > > > __aligned_u64 stack_size; > > > > __aligned_u64 tls; > > > > __aligned_u64 set_tid; > > > > __aligned_u64 set_tid_size; > > > > __aligned_u64 namespaces; > > > > __aligned_u64 namespaces_size; > > > > }; > > > > > > > > Then when we end up adding id mapping support for CLONE_NEWUSER we can > > > > extend this with: > > > > > > > > struct { > > > > struct { > > > > __aligned_u64 monotonic; > > > > __aligned_u64 boot; > > > > s/__aligned_u64/__s64/g > > > > Sorry, leftover from my first draft. > > > > > > } time; > > > > > > > > struct { > > > > /* id mapping members */ > > > > } user; > > > > } namespaces; > > > > > > > > Thoughts? Other ideas? > > > > > > Works for me. > > > > > > If we add the user namespace id mappings and then at some point a third > > > element for the time namespace appears it would also start to be mixed. > > > Just as you mentioned that a few mails ago. > > > > I think you misunderstand me or I'm misunderstanding you. That new time > > namespace member would go into struct time {} so > > > > struct { > > struct { > > __s64 monotonic; > > __s64 boot; > > __s64 someothertime; > > } time; > > > > struct { > > /* id mapping members */ > > } user; > > } namespaces; > > My question was about how does the kernel know how 'struct namespaces' > is structured. How can an older kernel (which only is aware of two > clocks) deal with a, like in this example, third clock. Will the size > '__aligned_u64 namespaces_size' be used for versioning? Yes, that would be the idea. I don't want to give the impression that I think this is the best solution. It's one solution that I think is feasible. But if we have something better that is also future proof I'm happy to hear ideas. Christian