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 AED77C10F29 for ; Tue, 17 Mar 2020 08:42:12 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 8EA49205ED for ; Tue, 17 Mar 2020 08:42:12 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726132AbgCQImL (ORCPT ); Tue, 17 Mar 2020 04:42:11 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:44213 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725862AbgCQImL (ORCPT ); Tue, 17 Mar 2020 04:42:11 -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 1jE7nP-0006jj-MB; Tue, 17 Mar 2020 08:41:55 +0000 Date: Tue, 17 Mar 2020 09:41:54 +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: clone3: allow creation of time namespace with offset Message-ID: <20200317084154.m2u76jqj5f47mxqc@wittgenstein> References: <20200317083043.226593-1-areber@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200317083043.226593-1-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:40AM +0100, Adrian Reber wrote: > This is an attempt to add time namespace support to clone3(). I am not > really sure which way clone3() should handle time namespaces. The time > namespace through /proc cannot be used with clone3() because the offsets > for the time namespace need to be written before a process has been > created in that time namespace. This means it is necessary to somehow > tell clone3() the offsets for the clocks. > > The time namespace offers the possibility to set offsets for > CLOCK_MONOTONIC and CLOCK_BOOTTIME. My first approach was to extend > 'struct clone_args` with '__aligned_u64 monotonic_offset' and > '__aligned_u64 boottime_offset'. The problem with this approach was that > it was not possible to set nanoseconds for the clocks in the time > namespace. > > One of the motivations for clone3() with CLONE_NEWTIME was to enable > CRIU to restore a process in a time namespace with the corresponding > offsets. And although the nanosecond value can probably never be > restored to the same value it had during checkpointing, because the > clock keeps on running between CRIU pausing all processes and CRIU > actually reading the value of the clocks, the nanosecond value is still > necessary for CRIU to not restore a process where the clock jumps back > due to CRIU restoring it with a nanonsecond value that is too small. > > Requiring nanoseconds as well as seconds for two clocks during clone3() > means that it would require 4 additional members to 'struct clone_args': > > __aligned_u64 tls; > __aligned_u64 set_tid; > __aligned_u64 set_tid_size; > + __aligned_u64 boottime_offset_seconds; > + __aligned_u64 boottime_offset_nanoseconds; > + __aligned_u64 monotonic_offset_seconds; > + __aligned_u64 monotonic_offset_nanoseconds; > }; > > To avoid four additional members to 'struct clone_args' this patchset > uses another approach: > > __aligned_u64 tls; > __aligned_u64 set_tid; > __aligned_u64 set_tid_size; > + __aligned_u64 timens_offset; > + __aligned_u64 timens_offset_size; Hm, so for set_tid we did set_tid and set_tid_size which makes sense because set_tid wasn't actually a struct. But I'm not a fan of establishing a pattern whereby we always have to grow two member, the object and it's size; at least when we're adding a struct. So at a first glance here are two possible ideas: - Don't add a size argument and assume that struct timens_offset won't grow. I'm not sure how likely it is it will grow. - Make the size the first member of struct timens_offset the size of the struct. (See examples for this pattern in the sched syscalls.) Christian