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=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS 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 F36C6C43331 for ; Tue, 24 Mar 2020 16:10:03 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D051220789 for ; Tue, 24 Mar 2020 16:10:03 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727628AbgCXQKD (ORCPT ); Tue, 24 Mar 2020 12:10:03 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:47999 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727545AbgCXQKD (ORCPT ); Tue, 24 Mar 2020 12:10:03 -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 1jGm7e-0003gz-Ic; Tue, 24 Mar 2020 16:09:46 +0000 Date: Tue, 24 Mar 2020 17:09:45 +0100 From: Christian Brauner To: Andrei Vagin , Arnd Bergmann , Adrian Reber Cc: 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: <20200324160945.orcm75avj2ol3eop@wittgenstein> References: <20200317083043.226593-1-areber@redhat.com> <20200319081137.GC223854@dcbz.redhat.com> <20200319102955.i7slokibkkysz6g6@wittgenstein> <20200320183355.GA118769@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200320183355.GA118769@gmail.com> Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org 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; } time; struct { /* id mapping members */ } user; } namespaces; Thoughts? Other ideas? Christian