linux/kernel/time/timekeeping.c, branch v3.19

Merge branch 'timers-2038-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2014-12-10T18:13:28Z

Pull more 2038 timer work from Thomas Gleixner: "Two more patches for the ongoing 2038 work: - New accessors to clock MONOTONIC and REALTIME seconds This is a seperate branch as Arnd has follow up work depending on this" * 'timers-2038-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timekeeping: Provide y2038 safe accessor to the seconds portion of CLOCK_REALTIME timekeeping: Provide fast accessor to the seconds part of CLOCK_MONOTONIC

time: Fix sign bug in NTP mult overflow warning

2014-11-25T06:18:34Z

In commit 6067dc5a8c2b ("time: Avoid possible NTP adjustment mult overflow") a new check was added to watch for adjustments that could cause a mult overflow. Unfortunately the check compares a signed with unsigned value and ignored the case where the adjustment was negative, which causes spurious warn-ons on some systems (and seems like it would result in problematic time adjustments there as well, due to the early return). Thus this patch adds a check to make sure the adjustment is positive before we check for an overflow, and resovles the issue in my testing. Reported-by: Fengguang Wu Debugged-by: pang.xunlei Signed-off-by: John Stultz Link: http://lkml.kernel.org/r/1416890145-30048-1-git-send-email-john.stultz@linaro.org Signed-off-by: Ingo Molnar

time: Fixup comments to reflect usage of timespec64

2014-11-21T19:59:59Z

Fix up a few comments that weren't updated when the functions were converted to use timespec64 structures. Acked-by: Arnd Bergmann Signed-off-by: John Stultz

time: Expose get_monotonic_coarse64() for in-kernel uses

2014-11-21T19:59:59Z

Adds a timespec64 based get_monotonic_coarse64() implementation that can be used as we convert internal users of get_monotonic_coarse away from using timespecs. Signed-off-by: John Stultz

time: Expose getrawmonotonic64 for in-kernel uses

2014-11-21T19:59:58Z

Adds a timespec64 based getrawmonotonic64() implementation that can be used as we convert internal users of getrawmonotonic away from using timespecs. Signed-off-by: John Stultz

time: Provide y2038 safe timekeeping_inject_sleeptime() replacement

2014-11-21T19:59:57Z

As part of addressing "y2038 problem" for in-kernel uses, this patch adds timekeeping_inject_sleeptime64() using timespec64. After this patch, timekeeping_inject_sleeptime() is deprecated and all its call sites will be fixed using the new interface, after that it can be removed. NOTE: timekeeping_inject_sleeptime() is safe actually, but we want to eliminate timespec eventually, so comes this patch. Signed-off-by: pang.xunlei Signed-off-by: John Stultz

time: Provide y2038 safe do_settimeofday() replacement

2014-11-21T19:59:57Z

The kernel uses 32-bit signed value(time_t) for seconds elapsed 1970-01-01:00:00:00, thus it will overflow at 2038-01-19 03:14:08 on 32-bit systems. This is widely known as the y2038 problem. As part of addressing "y2038 problem" for in-kernel uses, this patch adds safe do_settimeofday64() using timespec64. After this patch, do_settimeofday() is deprecated and all its call sites will be fixed using do_settimeofday64(), after that it can be removed. Signed-off-by: pang.xunlei Signed-off-by: John Stultz

time: Complete NTP adjustment threshold judging conditions

2014-11-21T19:59:56Z

The clocksource mult-adjustment threshold is [mult-maxadj, mult+maxadj], timekeeping_adjust() only deals with the upper threshold, but misses the lower threshold. This patch adds the lower threshold judging condition. Signed-off-by: pang.xunlei [jstultz: Minor fix for > 80 char line] Signed-off-by: John Stultz

time: Avoid possible NTP adjustment mult overflow.

2014-11-21T19:59:56Z

Ideally, __clocksource_updatefreq_scale, selects the largest shift value possible for a clocksource. This results in the mult memember of struct clocksource being particularly large, although not so large that NTP would adjust the clock to cause it to overflow. That said, nothing actually prohibits an overflow from occuring, its just that it "shouldn't" occur. So while very unlikely, and so far never observed, the value of (cs->mult+cs->maxadj) may have a chance to reach very near 0xFFFFFFFF, so there is a possibility it may overflow when doing NTP positive adjustment See the following detail: When NTP slewes the clock, kernel goes through update_wall_time()->...->timekeeping_apply_adjustment(): tk->tkr.mult += mult_adj; Since there is no guard against it, its possible tk->tkr.mult may overflow during this operation. This patch avoids any possible mult overflow by judging the overflow case before adding mult_adj to mult, also adds the WARNING message when capturing such case. Signed-off-by: pang.xunlei [jstultz: Reworded commit message] Signed-off-by: John Stultz

timekeeping: Provide y2038 safe accessor to the seconds portion of CLOCK_REALTIME

2014-10-29T14:15:40Z

ktime_get_real_seconds() is the replacement function for get_seconds() returning the seconds portion of CLOCK_REALTIME in a time64_t. For 64bit the function is equivivalent to get_seconds(), but for 32bit it protects the readout with the timekeeper sequence count. This is required because 32-bit machines cannot access 64-bit tk->xtime_sec variable atomically. [tglx: Massaged changelog and added docbook comment ] Signed-off-by: Heena Sirwani Reviewed-by: Arnd Bergman Cc: John Stultz Cc: opw-kernel@googlegroups.com Link: http://lkml.kernel.org/r/7adcfaa8962b8ad58785d9a2456c3f77d93c0ffb.1414578445.git.heenasirwani@gmail.com Signed-off-by: Thomas Gleixner