[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160220194310.02964d5f@lxorguk.ukuu.org.uk>
Date: Sat, 20 Feb 2016 19:43:10 +0000
From: One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To: Alexandre Belloni <alexandre.belloni@...e-electrons.com>
Cc: rtc-linux@...glegroups.com,
Alessandro Zummo <a.zummo@...ertech.it>,
Arnd Bergmann <arnd@...db.de>, Willy Tarreau <w@....eu>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] rtc: Add an option to invalidate dates in 2038
On Sat, 20 Feb 2016 20:10:44 +0100
Alexandre Belloni <alexandre.belloni@...e-electrons.com> 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.
Alan
Powered by blists - more mailing lists