From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Cc: rtc-linux@googlegroups.com,
Alessandro Zummo <a.zummo@towertech.it>,
Arnd Bergmann <arnd@arndb.de>, Willy Tarreau <w@1wt.eu>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] rtc: Add an option to invalidate dates in 2038
Date: Sat, 20 Feb 2016 19:43:10 +0000 [thread overview]
Message-ID: <20160220194310.02964d5f@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <1455995444-14146-1-git-send-email-alexandre.belloni@free-electrons.com>
On Sat, 20 Feb 2016 20:10:44 +0100
Alexandre Belloni <alexandre.belloni@free-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
next prev parent reply other threads:[~2016-02-20 19:43 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-20 19:10 Alexandre Belloni
2016-02-20 19:43 ` One Thousand Gnomes [this message]
2016-02-20 20:47 ` Alexandre Belloni
2016-02-20 22:16 ` Arnd Bergmann
2016-02-20 23:17 ` Alexandre Belloni
2016-02-20 23:42 ` Alexandre Belloni
2016-02-21 12:40 ` One Thousand Gnomes
2016-02-22 13:00 ` Alexandre Belloni
2016-02-22 13:43 ` One Thousand Gnomes
2016-02-22 15:44 ` Arnd Bergmann
2016-02-22 15:56 ` Alexandre Belloni
2016-02-22 16:18 ` Arnd Bergmann
2016-02-22 16:40 ` Alexandre Belloni
2016-02-22 16:41 ` Austin S. Hemmelgarn
2016-02-22 16:58 ` Alexandre Belloni
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160220194310.02964d5f@lxorguk.ukuu.org.uk \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=a.zummo@towertech.it \
--cc=alexandre.belloni@free-electrons.com \
--cc=arnd@arndb.de \
--cc=linux-kernel@vger.kernel.org \
--cc=rtc-linux@googlegroups.com \
--cc=w@1wt.eu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®