Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow

[Miroslav Lichvar <mlichvar@redhat.com>]

On Wed, Oct 07, 2015 at 03:47:19PM +0200, Arnd Bergmann wrote:
> On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote:
> > This patch sets a maximum value of the system time to prevent the system
> > time from getting too close to the overflow. The time can't be set to a
> > larger value. When the maximum is reached in normal time accumulation,
> > the clock will be stepped back by one week.
> 
> I can't see whether this is really a good idea: moving the time backwards
> will break all sorts of drivers that (incorrectly) expect the real
> time clock to have monotonic behavior, and quite often, file timestamps

Well, do these drivers break when the clock is stepped back by ntpd?
Maybe it would be better to fix them.

> are expected to be in the past in user space. A common example is
> 'make', which goes nuts when it sees files in the future.

Without the limit added by this patch make will go nuts just one week
later when the 32-bit time_t overflows to Dec 13 1901 and the files
will appear as 136 years in the future. How is that better?

> So for all I can tell, your patch only replaces one set of problems
> that happens at the time of the overflow with a different set of problems.

I think it converts a set of problems that are difficult to handle and
most people don't even know about to a single well known problem
(clock being stepped back).

I'd suggest to run "date -s @$[2**31 - 20]" on a 32-bit system and try
working in that.

-- 
Miroslav Lichvar