From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757054AbdHYOq1 (ORCPT ); Fri, 25 Aug 2017 10:46:27 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57770 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757037AbdHYOqZ (ORCPT ); Fri, 25 Aug 2017 10:46:25 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com E05F0C04B328 Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=prarit@redhat.com Subject: Re: [PATCH 2/2 v8] printk: Add monotonic, boottime, and realtime timestamps To: John Stultz , Joel Fernandes References: <1503582122-22841-1-git-send-email-prarit@redhat.com> <1503582122-22841-3-git-send-email-prarit@redhat.com> Cc: lkml , Mark Salyzyn , Jonathan Corbet , Petr Mladek , Sergey Senozhatsky , Steven Rostedt , Thomas Gleixner , Stephen Boyd , Andrew Morton , Greg Kroah-Hartman , "Paul E. McKenney" , Christoffer Dall , Deepa Dinamani , Ingo Molnar , Joel Fernandes , Kees Cook , Peter Zijlstra , Geert Uytterhoeven , "Luis R. Rodriguez" , Nicholas Piggin , "Jason A. Donenfeld" , Olof Johansson , Josh Poimboeuf , linux-doc@vger.kernel.org From: Prarit Bhargava Message-ID: Date: Fri, 25 Aug 2017 10:46:21 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 25 Aug 2017 14:46:25 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/24/2017 02:50 PM, John Stultz wrote: > On Thu, Aug 24, 2017 at 6:42 AM, Prarit Bhargava wrote: >> --- a/include/linux/timekeeping.h >> +++ b/include/linux/timekeeping.h >> @@ -239,6 +239,7 @@ static inline u64 ktime_get_raw_ns(void) >> extern u64 ktime_get_mono_fast_ns(void); >> extern u64 ktime_get_raw_fast_ns(void); >> extern u64 ktime_get_boot_fast_ns(void); >> +extern u64 ktime_get_real_offset(void); >> >> /* >> * Timespec interfaces utilizing the ktime based ones >> diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c >> index fc47863f629c..dd972bc5c88b 100644 >> --- a/kernel/printk/printk.c >> +++ b/kernel/printk/printk.c > ... >> + * printk_get_real_ns: - Return a realtime timestamp for printk messages >> + * On 32-bit systems selecting the real clock printk timestamp may lead to >> + * unlikely situations where a timestamp is wrong because the real time offset >> + * is read without the protection of a sequence lock. >> + */ >> +static u64 printk_get_real_ns(void) >> +{ >> + return ktime_get_mono_fast_ns() + ktime_get_real_offset(); >> +} >> + > ... >> diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c >> index d111039e0245..de07bb5ffef5 100644 >> --- a/kernel/time/timekeeping.c >> +++ b/kernel/time/timekeeping.c >> @@ -508,6 +508,11 @@ u64 notrace ktime_get_boot_fast_ns(void) >> } >> EXPORT_SYMBOL_GPL(ktime_get_boot_fast_ns); >> >> +u64 ktime_get_real_offset(void) >> +{ >> + return ktime_to_ns(tk_core.timekeeper.offs_real); >> +} >> + > > Apologies! One last nit here. So if we're going to export > ktime_get_real_offset(), folks are going to use it, and there is no > documentation about its very sketchy behavioral limits as an > interface, except elsewhere in the printk code. > > Instead of doing that, could you export a > __ktime_get_real_fast_ns_unsafe() function, which has its limits > (calculating the realtime w/o locks, thus may return completely bad > values occasionally) clearly documented in the timekeeping code? np. I'm going to copy the code for u64 notrace ktime_get_boot_fast_ns(void) but I'm unsure why the function is marked "notrace", and if __ktime_get_real_fast_ns_unsafe() must be as well? I don't see anything in the git log that indicates why the function is notrace. I've added Joel to this thread ... P.