lkml.org 
[lkml]   [2016]   [Dec]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [patch 5/6] [RFD] timekeeping: Provide optional 128bit math
    On Thu, Dec 8, 2016 at 8:29 PM, Ingo Molnar <mingo@kernel.org> wrote:
    >
    > * Ingo Molnar <mingo@kernel.org> wrote:
    >
    >>
    >> * Thomas Gleixner <tglx@linutronix.de> wrote:
    >>
    >> > If the timekeeping CPU is scheduled out long enough by a hypervisor the
    >> > clocksource delta multiplication can overflow and as a result time can go
    >> > backwards. That's insane to begin with, but people already triggered a
    >> > signed multiplication overflow, so a unsigned overflow is not necessarily
    >> > impossible.
    >> >
    >> > Implement optional 128bit math which can be selected by a config option.
    >>
    >> What's the rough VM interruption time that would trigger an overflow? Given that
    >> the clock shift tk_read_base::mult is often 1, isn't it 32-bit nsecs, i.e. 4
    >> seconds?
    >>
    >> That doesn't sound 'insanely long'.
    >>
    >> Or some other value?
    >
    > Ok, wasn't fully awake yet: more realistic values of the scaling factor on x86
    > would allow cycles input values of up to ~70 billion with 64-bit math, which would
    > allow deltas of up to about 1 minute with 64-bit math.

    So if I'm remembering properly, we pick mult/shift pairs such that the
    mult shouldn't overflow from ~10 minutes worth of cycles.

    > I think we should at least detect (and report?) the overflow and sanitize the
    > effects to the max offset instead of generating random overflown values.

    So with CONFIG_DEBUG_TIMEKEEPING, we do check to see if the cycle
    value is larger then the max_cycles and will report a warning. But
    this is done at interrupt time and not in the hotpath.

    thanks
    -john

    \
     
     \ /
      Last update: 2016-12-09 05:40    [W:4.423 / U:0.484 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site