Received: by 2002:a25:d783:0:0:0:0:0 with SMTP id o125csp375858ybg; Thu, 19 Mar 2020 01:12:52 -0700 (PDT) X-Google-Smtp-Source: ADFU+vtJXiEeqOOMqX7KIRLUaCx+OUL29GYPr7eCu/R/jVVwscoBg6FoniqZItVKEUew0J3OmyHW X-Received: by 2002:a9d:7d89:: with SMTP id j9mr1234898otn.47.1584605572177; Thu, 19 Mar 2020 01:12:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1584605572; cv=none; d=google.com; s=arc-20160816; b=id26oQh/+LBHDDs5eOAsjoKHrckpA8BAB2jh2+zgoDU9WnjusaNznIg9736EMDCdmf xfKclYhMXfh4jksfFs/M7RoEpRB8066HVRMZRCmtHAErba2tu61yI+g/RUJ1KtnWlhJ0 7iZDT7C7cqMWHNU/lrI4QUTeyFnKPLc6VsqNMXOdw3h6eKPBLJanUX/5ZGa1CKjl6Vz2 PTNNRFFyGF6AOqKzNHrX2xQaBkoFjmS2GC0wy+su7K9W7izocJxYjQU3arJmVc1DFr4n 412PvZjuywxLbdGxQzxajA42alHSl5+mt+duzJnVVpbFXFBetFI2BeXrn9mDB7QuHD9R mqwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:organization:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=T1NFGmp/ZfO2b8+xQcK8SU35k88uC0jA2Heq1vKlCdU=; b=ZLSSFEYyG9mlwNV+S78Gvr6jshY1Eur3rn3U0tY8YWWfF0e0heiun8MW08pfWIIiJO QrBRrXPdISp9ryMrR5ZYljVLy7f5u5HNHHz2rP9opyNWU+MUDEsWT7YZ/xob7nquHHda 1LGOtPietfMTE9j3eg+o/hvpgNBN+SeYwrWLJRCXDwAYV54jg6YMnHGAqllGekm2zKwt fNWZ5krceBG6E7GpXtPlEWLpkRGB8HWWqJZU/vnvDx3OH8Ws1xLCrZtNPyuUr65kJE55 JlLRQt/VtE2/sbxB7ws1S9dkdThiTrnB54yGRXaNe2shGMHs6LDMX6HP7xGsm5l9texw OUsg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ow1azw8U; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j192si658197oih.233.2020.03.19.01.12.39; Thu, 19 Mar 2020 01:12:52 -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; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=Ow1azw8U; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726867AbgCSILz (ORCPT + 99 others); Thu, 19 Mar 2020 04:11:55 -0400 Received: from us-smtp-delivery-74.mimecast.com ([216.205.24.74]:53049 "EHLO us-smtp-delivery-74.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725895AbgCSILz (ORCPT ); Thu, 19 Mar 2020 04:11:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1584605514; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=T1NFGmp/ZfO2b8+xQcK8SU35k88uC0jA2Heq1vKlCdU=; b=Ow1azw8UG+duFMw9atLpskBwUBODVOVm6TnpgYITR2YA9FLhAGPk9bXaUgbhxz5novhje6 7MEGCQV5HHZA7pvNcvk0u8Tey6SY1XKADhJ0jBchlmSc9+VHWzliuKGKD5pi5lNhf8OzPo I7mUnxJPLlo2DxkxyKCYWBEzkNH7WN4= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-137-8_ZP5jXTN323QX24HDHZtQ-1; Thu, 19 Mar 2020 04:11:48 -0400 X-MC-Unique: 8_ZP5jXTN323QX24HDHZtQ-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 44FAE13EA; Thu, 19 Mar 2020 08:11:46 +0000 (UTC) Received: from dcbz.redhat.com (ovpn-112-179.ams2.redhat.com [10.36.112.179]) by smtp.corp.redhat.com (Postfix) with ESMTPS id AE1776EFA8; Thu, 19 Mar 2020 08:11:39 +0000 (UTC) Date: Thu, 19 Mar 2020 09:11:37 +0100 From: Adrian Reber To: Arnd Bergmann Cc: Christian Brauner , 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: <20200319081137.GC223854@dcbz.redhat.com> References: <20200317083043.226593-1-areber@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux (5.5.8-200.fc31.x86_64) X-Load-Average: 1.26 0.61 0.49 X-Unexpected: The Spanish Inquisition X-GnuPG-Key: gpg --recv-keys D3C4906A Organization: Red Hat X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 18, 2020 at 11:18:53AM +0100, Arnd Bergmann wrote: > On Tue, Mar 17, 2020 at 9:32 AM 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; > > }; > > Wouldn't it be sufficient to have the two nanosecond values, rather > than both seconds and nanoseconds? With 64-bit nanoseconds > you can represent several hundred years, and these would > always start at zero during boot. I like this. Just using nanoseconds will make it easier and should indeed be enough. > Regardless of this, I think you need a signed offset, not unsigned. Right, that was just a quick test at some point. Christian and I have also been discussing this a bit and Christian prefers a pointer to a struct. Maybe something like this: __aligned_u64 tls; __aligned_u64 set_tid; __aligned_u64 set_tid_size; + __aligned_u64 timens_offset; }; 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; }; But setting the time namespace offset is probably something which does not happen very often while using clone3(), so maybe the pointer to a struct approach is better. I will resend the patches using the pointer to a struct approach if there are no other ideas how to do this. Adrian