Re: [PATCH] timekeeping: Force upper bound for setting CLOCK_REALTIME

2019-03-26 Thread Thomas Gleixner
On Tue, 26 Mar 2019, Arnd Bergmann wrote: > On Tue, Mar 26, 2019 at 1:31 PM Thomas Gleixner wrote: > > > > On Tue, 26 Mar 2019, Miroslav Lichvar wrote: > > > On Sat, Mar 23, 2019 at 11:36:19AM +0100, Thomas Gleixner wrote: > > > > It is reasonable to force an upper bound for the various methods of

Re: [PATCH] timekeeping: Force upper bound for setting CLOCK_REALTIME

2019-03-26 Thread Arnd Bergmann
On Tue, Mar 26, 2019 at 1:31 PM Thomas Gleixner wrote: > > On Tue, 26 Mar 2019, Miroslav Lichvar wrote: > > On Sat, Mar 23, 2019 at 11:36:19AM +0100, Thomas Gleixner wrote: > > > It is reasonable to force an upper bound for the various methods of > > > setting > > > CLOCK_REALTIME. Year 2262 is t

Re: [PATCH] timekeeping: Force upper bound for setting CLOCK_REALTIME

2019-03-26 Thread Thomas Gleixner
On Tue, 26 Mar 2019, Miroslav Lichvar wrote: > On Sat, Mar 23, 2019 at 11:36:19AM +0100, Thomas Gleixner wrote: > > 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

Re: [PATCH] timekeeping: Force upper bound for setting CLOCK_REALTIME

2019-03-26 Thread Miroslav Lichvar
On Sat, Mar 23, 2019 at 11:36:19AM +0100, Thomas Gleixner wrote: > 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.

[PATCH] timekeeping: Force upper bound for setting CLOCK_REALTIME

2019-03-23 Thread Thomas Gleixner
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