[lkml]   [2012]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    Subject[PATCH 0/2][RFC] Better handling of insane CMOS values
    So CAI Qian noticed recent boot trouble on a machine that had its CMOS
    clock configured for the year 8200.

    While running with a crazy CMOS clock isn't advised, and a simple
    "don't do that" might be reasonable, the behavior has in effect
    regressed recently due to changes in the hrtimer/timekeeping

    This patchset tries to resolve this issue in two ways:
    1) Change ktime_get_update_offsets to match ktime_get and avoid
    possible precision loss with extremely large timespecs.

    2) Catch any stop attempt to set the time to a value (circa the
    year 2264) large enough to overflow ktime_t.

    The end fix here might be an either/or/both combination of these
    two changes, so I wanted to send them out for comment. I'm also
    looking at further ways to test and improve robustness around
    these more extreme time values.

    I've also only been able to lightly test. If you want to try this out
    you can add the following to timekeeping_init after the
    read_persistent_clock() call:

    now.tv_sec = 196469280000LL;


    Cc: Ingo Molnar <>
    Cc: Peter Zijlstra <>
    Cc: Prarit Bhargava <>
    Cc: Thomas Gleixner <>
    Cc: Zhouping Liu <>
    Cc: CAI Qian <>

    John Stultz (2):
    [RFC] time: Fix problem with large timespecs &
    [RFC] time: Limit time values that would overflow ktime_t

    kernel/time/timekeeping.c | 40 ++++++++++++++++++++++++++++++----------
    1 file changed, 30 insertions(+), 10 deletions(-)


     \ /
      Last update: 2012-07-31 09:22    [W:0.040 / U:48.804 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site