Skip to content

L
linux
Switch branch/tag
  1. 19 Dec, 2015 1 commit
  3. 17 Dec, 2015 4 commits
    • John Stultz's avatar
      timekeeping: Cap adjustments so they don't exceed the maxadj value · ec02b076
      John Stultz authored 
      Thus its been occasionally noted that users have seen
confusing warnings like:

    Adjusting tsc more than 11% (5941981 vs 7759439)

We try to limit the maximum total adjustment to 11% (10% tick
adjustment + 0.5% frequency adjustment). But this is done by
bounding the requested adjustment values, and the internal
steering that is done by tracking the error from what was
requested and what was applied, does not have any such limits.

This is usually not problematic, but in some cases has a risk
that an adjustment could cause the clocksource mult value to
overflow, so its an indication things are outside of what is
expected.

It ends up most of the reports of this 11% warning are on systems
using chrony, which utilizes the adjtimex() ADJ_TICK interface
(which allows a +-10% adjustment). The original rational for
ADJ_TICK unclear to me but my assumption it was originally added
to allow broken systems to get a big constant correction at boot
(see adjtimex userspace package for an example) which would allow
the system to work w/ ntpd's 0.5% adjustment limit.

Chrony uses ADJ_TICK to make very aggressive short term corrections
(usually right at startup). Which push us close enough to the max
bound that a few late ticks can cause the internal steering to push
past the max adjust value (tripping the warning).

Thus this patch adds some extra logic to enforce the max adjustment
cap in the internal steering.

Note: This has the potential to slow corrections when the ADJ_TICK
value is furthest away from the default value. So it would be good to
get some testing from folks using chrony, to make sure we don't
cause any troubles there.

Cc: Miroslav Lichvar <mlichvar@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Tested-by: default avatarMiroslav Lichvar <mlichvar@redhat.com>
Reported-by: default avatarAndy Lutomirski <luto@kernel.org>
Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      ec02b076
    • DengChao's avatar
      ntp: Fix second_overflow's input parameter type to be 64bits · c7963487
      DengChao authored 
      The function "second_overflow" uses "unsign long"
as its input parameter type which will overflow after
year 2106 on 32bit systems.

Thus this patch replaces it with time64_t type.

While the 64-bit division is expensive, "next_ntp_leap_sec"
has been calculated already, so we can just re-use it in the
TIME_INS/DEL cases, allowing one expensive division per
leapsecond instead of re-doing the divsion once a second after
the leap flag has been set.
Signed-off-by: default avatarDengChao <chao.deng@linaro.org>
[jstultz: Tweaked commit message]
Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      c7963487
    • DengChao's avatar
      ntp: Change time_reftime to time64_t and utilize 64bit __ktime_get_real_seconds · 0af86465
      DengChao authored 
      The type of static variant "time_reftime" and the call of
get_seconds in ntp are both not y2038 safe.

So change the type of time_reftime to time64_t and replace
get_seconds with __ktime_get_real_seconds.

The local variant "secs" in ntp_update_offset represents
seconds between now and last ntp adjustment, it seems impossible
that this time will last more than 68 years, so keep its type as
"long".
Reviewed-by: default avatarJohn Stultz <john.stultz@linaro.org>
Signed-off-by: default avatarDengChao <chao.deng@linaro.org>
[jstultz: Tweaked commit message]
Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      0af86465
    • DengChao's avatar
      timekeeping: Provide internal function __ktime_get_real_seconds · dee36654
      DengChao authored 
      In order to fix Y2038 issues in the ntp code we will need replace
get_seconds() with ktime_get_real_seconds() but as the ntp code uses
the timekeeping lock which is also used by ktime_get_real_seconds(),
we need a version without locking.
Add a new function __ktime_get_real_seconds() in timekeeping to
do this.
Reviewed-by: default avatarJohn Stultz <john.stultz@linaro.org>
Signed-off-by: default avatarDengChao <chao.deng@linaro.org>
Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      dee36654
  5. 16 Dec, 2015 9 commits
  7. 15 Dec, 2015 26 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7