Re: [PATCH] rtc: Add an option to invalidate dates in 2038

[Alexandre Belloni]

On 20/02/2016 at 19:43:10 +0000, One Thousand Gnomes wrote :
> On Sat, 20 Feb 2016 20:10:44 +0100
> Alexandre Belloni <alexandre.belloni@xxxxxxxxxxxxxxxxxx> wrote:
> 
> > hctosys is setting the system time from the kernel. This means that 32bit
> > system can get their time set to a date after the 31bit time_t overflow.
> > 
> > This is currently an issue as userspace is not yet ready to handle those
> > dates and may break. For example systemd's usage of timerfd shows that the
> > timerfd will always fire immediately because it can't be set at a date
> > after the current date.
> > 
> > The new RTC_INVALID_2038 option will make sure that date after 03:09:07 on
> > Jan 19 2038 are invalid. This is 5 minutes before the 31bit overflow. This
> > leaves enough time for userspace to react and is short enough to make the
> > issue visible.
> 
> This is kind of pointless. You replace loading the RTC and discovering
> the time isn't supported by your system with not loading he RTC and
> discovering your system clock is magically and almost un-debuggably
> wrong, and when something like NTP syncs it, breaks anyway.
> 
> The only way to deal with 2038 is to fix your user space. People need to
> deal with reality, even if it's not all pink unicorns and rainbows.
> 

Actually, I'm not trying to solve the 2038 issue.

But in the current state on 32 bit platforms, while the kernel is able
to handle a 64bit date, userspace is not. The main issue is that
distributions use HCTOSYS so if the RTC is set to a date after 2038
(which we know is currently bogus), the kernel will set a system time to
that date.

This result in a system that fails when using timerfd, The timerfd will
always fire immediately (until, as some people pointed out, we have
relative timers).

This is know to break systemd [1] but I have had reports for other
failing applications.

I understand this is a workaround and I plan to switch the default to n
once libc and critical userspace is able to handle 64 bit time.

The other way of solving that is to get back to a 32 bit time_t
internally until we switch the whole userspace to a 64 bit time_t but I
don't think this is practical.

[1] https://github.com/systemd/systemd/issues/1143

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com