Re: [PATCH 1/2] [RFC] time: Fix problem with large timespecs & ktime_get_update_offsets

Thomas Gleixner
2012-08-01T06:52:46Z

On Tue, 31 Jul 2012, John Stultz wrote:
> There's currently a slight difference in ktime_get_update_offsets()
> vs ktime_get() which can result in boot time crashes when booting
> with insane CMOS clock values larger then ~2264.
>
> ktime_get() does basically the following:
> return timespec_to_ktime(timespec_add(xtime, wall_to_monotonic))
>
> Where as ktime_get_update_offsets does approximately:
> return ktime_sub(timespec_to_ktime(xtime), realtime_offset);
>
> The problem is, at boot we set xtime = year 8200 and
> wall_to_monotonic = year -8200, ktime_get adds both values, mostly
> nulling the difference out (leaving only how long the system has been
> up), then converts that relatively small value to a ktime_t properly
> without losing any information.
>
> ktime_get_update_offsets however, since it converts xtime (again set
> to some value greater then year 8200), to a ktime, it gets clamped at
> KTIME_MAX, then we subtract realtime_offset, which is _also_ clamped
> at KTIME_MAX, resulting in us always returning almost[1] zero. This
> causes us to stop expiring timers.
>
> Now, one of the reasons Thomas and I changed the logic was that using
> the precalculated realtime_offset was slightly more efficient then
> re-adding xtime and wall_to_monotonic's components separately. But
> how valuable this unmeasured slight efficiency is vs extra
> robustness for crazy time values is questionable.
>
> So switch back to the ktime_get implementation for
> ktime_get_update_offsets

NAK.

You're papering over the real problem: Using crap values without
sanity checking them in the first place.

All your patch does is papering over the problem. Heck, year 8200 is
obvious bullshit, so we can detect and reject it.

Thanks,

tglx