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 plenty enough even for esoteric embedded > > systems. That results in an upper bound of year 2232 for setting the time. > > The patch looks good to me. > > I like this approach better than using a larger value closer to the > overflow (e.g. one week) and stepping the clock back automatically > when the clock reaches that time, but I suspect it might possibly > break more tests (or any unusual applications messing with time) as a > much larger interval is now EINVAL.
I'm fine with breaking a few tests on the way rather than having undefined behaviour and the constant flow of patches tackling the wrong end of the stick. Thanks, tglx