Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1427935

Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime

From John Stultz <john.stultz@linaro.org>
Newsgroups linux.kernel
Subject Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime
Date 2016-06-21 18:30 +0200
Message-ID <rMwIO-8bK-43@gated-at.bofh.it> (permalink)
References <rL4lA-8sx-33@gated-at.bofh.it> <rMnFv-2dg-5@gated-at.bofh.it> <rMpnX-3mT-21@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Tue, Jun 21, 2016 at 1:32 AM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote:
>> Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann:
>>
> Compared to the previous __getnstimeofday(), the difference is
>
> - using "monotonic" timebase instead of "real", so the zero time
>   is when the system booted rather than Jan 1 1970

I haven't looked at the details of the calling code, but I'd worry for
crypto uses, especially if its being used for entropy collection,
using the monotonic clock instead of the realtime clock might be
problematic.

> - "raw" means we don't honor updates for the rate based on ntp,
>   which is probably better as the ntp state might be observable
>   over the net (it probably doesn't matter, but it can't hurt)

So... this feels like a very vague explanation, and the lack of
frequency correction here probably need a really good comment. Keeping
multiple time domains is usually asking for trouble, but we added the
MONOTONIC_RAW clock to address a few cases where people really wanted
an abstract hardware counter, which was unaffected by frequency
corrections. I'd really make sure its clear why this is what you want
vs the standard system time domain so we don't run into problems
understanding it later.

> - "fast" means that in very rare cases, the time might appear
>   to go backwards (it probably can't happen here because you are not
>   called in an NMI).

"fast" really means "safe-for-nmi wrt to locking".  The tradeoff being
that when frequency adjustments occur, and if your code is delayed,
you might see time go backwards by a small amount. This allows
tracing/sched code (or other code called from NMI)  to not have to
duplicate the timekeeping infrastructure.

I think without a much better explanation, using the "fast" method
isn't really warranted here.

thanks
-john

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] crypto: use timespec64 for jent_get_nstime Arnd Bergmann <arnd@arndb.de> - 2016-06-17 18:00 +0200
  Re: [PATCH] crypto: use timespec64 for jent_get_nstime Stephan Mueller <smueller@chronox.de> - 2016-06-18 10:20 +0200
  Re: [PATCH] crypto: use timespec64 for jent_get_nstime Stephan Mueller <smueller@chronox.de> - 2016-06-21 08:50 +0200
    Re: [PATCH] crypto: use timespec64 for jent_get_nstime Stephan Mueller <smueller@chronox.de> - 2016-06-21 10:40 +0200
    Re: [PATCH] crypto: use timespec64 for jent_get_nstime Arnd Bergmann <arnd@arndb.de> - 2016-06-21 10:40 +0200
      Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime John Stultz <john.stultz@linaro.org> - 2016-06-21 18:30 +0200
        Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime Stephan Mueller <smueller@chronox.de> - 2016-06-21 18:40 +0200
          Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime John Stultz <john.stultz@linaro.org> - 2016-06-21 18:50 +0200
            Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime Stephan Mueller <smueller@chronox.de> - 2016-06-21 19:00 +0200
              Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime Stephan Mueller <smueller@chronox.de> - 2016-06-21 19:20 +0200
              Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime John Stultz <john.stultz@linaro.org> - 2016-06-21 19:20 +0200
              Re: [Y2038] [PATCH] crypto: use timespec64 for jent_get_nstime Stephan Mueller <smueller@chronox.de> - 2016-06-21 19:40 +0200

csiph-web