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 69908C4332B for ; Thu, 19 Mar 2020 10:30:14 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 484FD20739 for ; Thu, 19 Mar 2020 10:30:14 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726911AbgCSKaN (ORCPT ); Thu, 19 Mar 2020 06:30:13 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:51109 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726936AbgCSKaN (ORCPT ); Thu, 19 Mar 2020 06:30:13 -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 1jEsR2-00065s-3p; Thu, 19 Mar 2020 10:29:56 +0000 Date: Thu, 19 Mar 2020 11:29:55 +0100 From: Christian Brauner To: Arnd Bergmann Cc: Adrian Reber , Eric Biederman , Pavel Emelyanov , Oleg Nesterov , Dmitry Safonov <0x7f454c46@gmail.com>, Andrei Vagin , "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: <20200319102955.i7slokibkkysz6g6@wittgenstein> References: <20200317083043.226593-1-areber@redhat.com> <20200319081137.GC223854@dcbz.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Sender: linux-api-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org 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. Christian