On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote:
On systems with 32-bit time_t there are quite a few problems that applications may have with time overflowing in year 2038. Beside getting to an unexpected state by not checking integer operations with time_t variables, some system calls have unexpected behavior, e.g. the system time can't be set back to the current time (negative value), timers with the ABSTIME flag can't be set (negative value) or they expire immediately (current time is always larger).
It would be unrealistic to expect all applications to be able to handle all these problems. Year 2038 is still many years away, but this can be a problem even now. The clock can get close to the overflow accidentally or maliciously, e.g. when it is synchronized over network by NTP or PTP.
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.
A new kernel sysctl time_max is added to select the maximum time. It can be set to 0 for no limit, 1 for one week before 32-bit time_t overflow, and 2 for one week before ktime_t overflow. The default value is 1 with 32-bit time_t and 2 with 64-bit time_t. This can be changed later to be always 2 when 64-bit versions of system calls working with time_t are available.
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 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.
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.
Arnd