• Thomas Gleixner's avatar
    timekeeping: Force upper bound for setting CLOCK_REALTIME · 7a8e61f8
    Thomas Gleixner authored
    Several people reported testing failures after setting CLOCK_REALTIME close
    to the limits of the kernel internal representation in nanoseconds,
    i.e. year 2262.
    
    The failures are exposed in subsequent operations, i.e. when arming timers
    or when the advancing CLOCK_MONOTONIC makes the calculation of
    CLOCK_REALTIME overflow into negative space.
    
    Now people start to paper over the underlying problem by clamping
    calculations to the valid range, but that's just wrong because such
    workarounds will prevent detection of real issues as well.
    
    It is reasonable to force an upper bound for the various methods of setting
    CLOCK_REALTIME. Year 2262 is the absolute upper bound. Assume a maximum
    uptime of 30 years which is plenty enough even for esoteric embedded
    systems. That results in an upper bound of year 2232 for setting the time.
    
    Once that limit is reached in reality this limit is only a small part of
    the problem space. But until then this stops people from trying to paper
    over the problem at the wrong places.
    Reported-by: default avatarXiongfeng Wang <wangxiongfeng2@huawei.com>
    Reported-by: default avatarHongbo Yao <yaohongbo@huawei.com>
    Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Stephen Boyd <sboyd@kernel.org>
    Cc: Miroslav Lichvar <mlichvar@redhat.com>
    Cc: Arnd Bergmann <arnd@arndb.de>
    Cc: Richard Cochran <richardcochran@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Link: https://lkml.kernel.org/r/alpine.DEB.2.21.1903231125480.2157@nanos.tec.linutronix.de
    7a8e61f8
time.c 24.7 KB