On Thu, Dec 8, 2016 at 8:29 PM, Ingo Molnar <mi...@kernel.org> wrote: > > * Ingo Molnar <mi...@kernel.org> wrote: > >> >> * Thomas Gleixner <t...@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
