On Tuesday, June 21, 2016 8:20:10 AM CEST Stephan Mueller wrote: > Am Freitag, 17. Juni 2016, 17:59:41 schrieb Arnd Bergmann: > > Hi Arnd, > > > The jent_get_nstime() function uses __getnstimeofday() to get > > something similar to a 64-bit nanosecond counter. As we want > > to get rid of struct timespec to fix the y2038 overflow, > > this patch changes the code to use __getnstimeofday64() > > instead, which returns a timespec64 structure. > > > > Nothing changes about the algorithm, but it looks like it > > might be better to use > > > > *out = ts.tv_sec * NSEC_PER_SEC + ts.tv_nsec; > > > > or even > > > > *out = ktime_get_raw_fast_ns(); > > I tested ktime_get_raw_fast_ns and it works perfectly well for the use case, > i.e. the RNG behavior is indistinguishable from RDTSC on x86. > > Which time source is used for this function? I am wondering about > architectures other than X86. (adding John Stultz to Cc, he can correct me if I say something wrong) All ktime_get_* and *get*timeofday() functions use the same clocksource, which is configurable and picked from the available clocksources, using a combination of reliability, latency for reading and accuracy. 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 - "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) - "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). There may be other clocksources in the system that are more appropriate for the purpose of jent_get_nstime(), but I don't think we have a way of exposing them at the moment, because we have not needed it in the past. I assume what you want is the highest-resolution clocksource, and you don't really care about > Note, this function is used as a fallback when random_get_entropy is not > implemented. In addition the Jitter RNG has an online health test which will > catch the failure of the time stamp operation. Hence, even if this function > may not be suitable on one or the other arch, it should not hurt though. Ok. For the ARM architecture, I think most (maybe all) of the modern ARMv7 platforms have either an architected "global timer" or have their own replacement, while the majority of the older ARMv4/v5/v6 machines don't have one. However, there are some machines that implement "sched_clock" but don't implement get_cycles (which is the default for random_get_entropy()). It's possible that there are cases where it's better to call sched_clock() than ktime_get_raw_fast_ns() as a fallback, though I could not find specific examples so far. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
