Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp1428766imj; Fri, 8 Feb 2019 01:04:21 -0800 (PST) X-Google-Smtp-Source: AHgI3IYamzHxWcJUinBj6AgzfdjX2XJt4dNiHGyldNXQvSj6dntZyqL4skJcAPvZGMGsFjORoaIf X-Received: by 2002:a63:4f5e:: with SMTP id p30mr9004147pgl.71.1549616660905; Fri, 08 Feb 2019 01:04:20 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549616660; cv=none; d=google.com; s=arc-20160816; b=fENSI/+SdMOhg07/Qd+YGG6odtnkEDyorMtTGukg3BJQYO1QrFXskkGyCCAd3EXULh rFMWVmFqb1uzYZ8A876+zoLy+mu4I53r4XWDa52nKDtqkbSSOfumuUwSXnbcTCvfC8tU ZOqr5Jqaz9xDyzDdfro3a/bC+bvf0onJXpcxpqgTKaBKw6blpgUmxns065FJaFK2aedz ZmcGaVUeQs0k8Rvnvd86udkJMmT+DP9DaGMmDHL9U+rPQxrw7TJMojDdy79qrIxpK+SE HfG0aaB3bDsi1udX8hNiYyvlhfL8bX6okJ3Qx4s2eFplRpiFT/3uRg+2jZFdsSNe7GhA wWyw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=XO2QqIzd/2wsZWXY5lU5a7LjREkFwpyihI12GITFRaE=; b=E5GwJ6HJ2RTgxnc62yFKtERx9s/iEmp11D9YW+hccPDkJ3UAgwi1wTZe57mf5V4XR5 qvJ762VqJucpzak8aBX+NeYWrA6EsQFNLyHBzAtKy0qKdDOFKrqmPjXgjA0ZVrJraHQd Huvtndh/taRx7SQ+ljN1r0O97zApN+QejNnAf3d3k8hDr3mp7AptGBQ3+Cj5oK3XPOXe igLtC4FZoiiHfXGDkTRBD87sXgDeQoZNhUyhTBJn/1sSUGSlteV0Eas/hQQ/zRK/b7Za Uz6cTSYV5v1OV0p1M2smBw4lZKQ2smouq9RICY0eXM/XjXr6lLcVQxWpZPUBeZyJ/6hR wa5A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=cHYUDXs0; 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=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 5si1591441pgc.290.2019.02.08.01.04.03; Fri, 08 Feb 2019 01:04:20 -0800 (PST) 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=@gmail.com header.s=20161025 header.b=cHYUDXs0; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727496AbfBHJDE (ORCPT + 99 others); Fri, 8 Feb 2019 04:03:04 -0500 Received: from mail-pf1-f195.google.com ([209.85.210.195]:45588 "EHLO mail-pf1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726115AbfBHJDD (ORCPT ); Fri, 8 Feb 2019 04:03:03 -0500 Received: by mail-pf1-f195.google.com with SMTP id j3so1362553pfi.12; Fri, 08 Feb 2019 01:03:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=XO2QqIzd/2wsZWXY5lU5a7LjREkFwpyihI12GITFRaE=; b=cHYUDXs0ksagr3AbAAYZEjCZBjLKWgwPfUhdltVMvSvfaYJDKCMe/c/lFrsVzcSicD xMQyb+Odr4rS0c87VhL6//2HCqJSVJdmLa2LnxS7BVzuDztZazXy0dxIyt++uY36R8hY oTOmARw99ziclhaTWmCGrE9+ORTiBy2GxV/nue1HaQs8IUbFbRa7F9ZLWKDDQW+6JaYt i1/KiPlqZtwLXQiQRVGS8HNJmx+XdSG4XXQJXgMvKrWZbNy+3EvOecpidhiqoJpoO5KC Z6ZCb6GvcazS1ISYhbnIF48CN4w2080D8tVmbWVr341rU9tENkX1tJxRm9ocKWA7rS1s Tc6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=XO2QqIzd/2wsZWXY5lU5a7LjREkFwpyihI12GITFRaE=; b=prIKqQi12GA4QEQCKEEzuZY62PBaY5RLkvV4avnPqyJF0P1qVRDqTQ8MKFH6Mnk2dr 39QCbgGwj/BLfkX9PiyCSIo7ml+QwYCymenDQR5gqUtiuQ4XgE3VdPZ+FGfY4wDN/FeF KfGnwSLJC8jriJib2ULz3Q6pXx/DAoOel7dP1XYo5cswIH8R+DMGMESn453kITo11N5G yg48+Rvru3PsFP8Pms2uqhSFyz4/wEMHtDIayu0kDommzE953A+HHEH7XJpCRf+mgQFf AKMDmDKmyDL+cc8UPacG2vJW9xPtbO6YKAvT2NKds9Sz7iwbfGj/JzoOdvC8Yylua7aO ORwA== X-Gm-Message-State: AHQUAuazXb001ZxwuI9akCEaPClP/AvY6d5/NEA/rQDdix2H09WkuBwv hfJz1b1eBKYmQPOfk3x03m4= X-Received: by 2002:a62:9111:: with SMTP id l17mr21020002pfe.200.1549616582151; Fri, 08 Feb 2019 01:03:02 -0800 (PST) Received: from gmail.com (c-73-140-212-29.hsd1.wa.comcast.net. [73.140.212.29]) by smtp.gmail.com with ESMTPSA id h129sm4224899pfb.110.2019.02.08.01.03.00 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 08 Feb 2019 01:03:01 -0800 (PST) Date: Fri, 8 Feb 2019 01:02:59 -0800 From: Andrei Vagin To: Thomas Gleixner Cc: Dmitry Safonov , linux-kernel@vger.kernel.org, Andrei Vagin , Adrian Reber , Andy Lutomirski , Andy Tucker , Arnd Bergmann , Christian Brauner , Cyrill Gorcunov , Dmitry Safonov <0x7f454c46@gmail.com>, "Eric W. Biederman" , "H. Peter Anvin" , Ingo Molnar , Jeff Dike , Oleg Nesterov , Pavel Emelyanov , Shuah Khan , containers@lists.linux-foundation.org, criu@openvz.org, linux-api@vger.kernel.org, x86@kernel.org Subject: Re: [PATCH 03/32] timens: Introduce CLOCK_MONOTONIC offsets Message-ID: <20190208090258.GA31765@gmail.com> References: <20190206001107.16488-1-dima@arista.com> <20190206001107.16488-4-dima@arista.com> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 07, 2019 at 10:40:55PM +0100, Thomas Gleixner wrote: > On Wed, 6 Feb 2019, Dmitry Safonov wrote: > > #include "timekeeping.h" > > #include "posix-timers.h" > > @@ -1041,6 +1042,9 @@ SYSCALL_DEFINE2(clock_gettime, const clockid_t, which_clock, > > > > error = kc->clock_get(which_clock, &kernel_tp); > > > > + if (!error && kc->clock_timens_adjust) > > + timens_clock_from_host(which_clock, &kernel_tp); > > Why are you adding this conditional instead of sticking the offset > magic into the affected ->clock_get() implementations? > > That spares you the switch() and the !offsets conditional. > > > +static void clock_timens_fixup(int clockid, struct timespec64 *val, bool to_ns) > > +{ > > + struct timens_offsets *ns_offsets = current->nsproxy->time_ns->offsets; > > + struct timespec64 *offsets = NULL; > > + > > + if (!ns_offsets) > > + return; > > + > > + if (val->tv_sec == 0 && val->tv_nsec == 0) > > + return; > > I have no idea why 0/0 is special. Initially this function was introduced to apply timens offsets in do_timer_settime and there it is special and means that the timer should be disarmed. Now this functions is used in many other places and this check defenetly sould not be here. > > > + > > + switch (clockid) { > > + case CLOCK_MONOTONIC: > > + case CLOCK_MONOTONIC_RAW: > > + case CLOCK_MONOTONIC_COARSE: > > + offsets = &ns_offsets->monotonic_time_offset; > > + break; > > + } > > + > > + if (!offsets) > > + return; > > + > > + if (to_ns) > > + *val = timespec64_add(*val, *offsets); > > + else > > + *val = timespec64_sub(*val, *offsets); > > +} > > + > > +void timens_clock_to_host(int clockid, struct timespec64 *val) > > Does this really need to be an out of line call? The idea was to collect all the logic about timens offsets in one place. clock_timens_fixup() is used in all places where we need apply timens offsets (clock_gettim, posix timers, clock_nanosleep, timerfd, uptime_proc_show). > If you stick this into the > clock_get() implementations then it boils down to: clock_get() is called from clock_gettime and from common_timer_get(). In common_timer_get(), we expect to get time in the root time namespace. but I think we can handle this. For example, we can introduce a new flag CLOCL_TIMENS and kc->clock_get(which_clock | CLOCK_TIMENS, &tp) will return time in a current time namespace. kc->clock_get(which_clock, &tp) will return time in the root time namespace. > > static inline void timens_add_monotonic(struct timespec64 *ts) > { > struct timens_offsets *ns_offsets = current->nsproxy->time_ns->offsets; > > if (ns_offsets) > *ts = timespec64_add(*ts, ns_offsets->monotonic_time_offset); > } > > and > > static int posix_ktime_get_ts(clockid_t which_clock, struct timespec64 *tp) > { > ktime_get_ts64(tp); > timens_add_monotonic(tp); > return 0; > } > > Hmm? Yes, we can do this. I like this idea. This will allow us to remove timens_clock_to_host(), but I am not sure that we will be able to do something similar with timens_clock_from_host, which is used to apply offsets for timers. I need to look at the timer code again. Thanks, Andrei > > Thanks, > > tglx >