On Tue, Jun 21, 2016 at 12:37 PM, Arnd Bergmann <arnd@xxxxxxxx> wrote: > On Tuesday, June 21, 2016 12:05:06 PM CEST John Stultz wrote: >> On Tue, Jun 21, 2016 at 11:49 AM, Stephan Mueller <smueller@xxxxxxxxxx> wrote: >> > Am Dienstag, 21. Juni 2016, 11:11:42 schrieb John Stultz: >> > >> > Hi John, >> > >> >> I don't see in the above an explanation of *why* you're using >> >> ktime_get_raw_ns() instead of ktime_get_ns(). >> > >> > Could you help me understand what the difference is or point me to some >> > documentation? I understood that we only talked about the _raw variant. >> >> Using specialized interfaces with subtle semantics w/o understanding >> them is sort of my concern here. >> >> There are reasons why you might want to use the ktime_get_raw_ns() >> interface over ktime_get_ns(), but they have not been made clear in >> the comment. Arnd discussed some potential concerns that the freq >> adjustment done by ntp might be somewhat predictable/controlled by >> remote parties, which could have some effect in the calculation. That >> feels a little overly vague to me, but I'm no crypto expert, so if >> that is a reasonable concern, then it should be a conscious and >> documented decision. > > My original patch changed __getnstimeofday() to __getnstimeofday64(), > which kept the original semantics of not warning in case the clock > source is suspended (which is the only different to the normal > getnstimeofday{,64}(). > > I did the patch a while time ago along with a number of other patches > that I never sent out until last week, so I don't remember the > reasoning for suggesting ktime_get_raw_fast_ns() over ktime_get_raw_ns(), > but I sure wanted to keep the non-warning behavior, and ktime_get_ns() > warns on timekeeping_suspended() while the other two don't. Right. But this code isn't called in late suspend or early resume is it? > If we don't care about the non-warning aspect, ktime_get_ns() makes > most sense here, and the original code should probably have used > getnstimeofday() as well. This is what I suspect as well. But again, I don't mind if folks use the specialized interfaces, as long as they document a clear reason for it. Especially for things like crypto where intuition isn't always the best guide. thanks -john -- 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