From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759407AbcBTUrZ (ORCPT ); Sat, 20 Feb 2016 15:47:25 -0500 Received: from down.free-electrons.com ([37.187.137.238]:37387 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1759382AbcBTUrW (ORCPT ); Sat, 20 Feb 2016 15:47:22 -0500 Date: Sat, 20 Feb 2016 21:47:15 +0100 From: Alexandre Belloni To: One Thousand Gnomes Cc: rtc-linux@googlegroups.com, Alessandro Zummo , Arnd Bergmann , Willy Tarreau , linux-kernel@vger.kernel.org Subject: Re: [PATCH] rtc: Add an option to invalidate dates in 2038 Message-ID: <20160220204715.GJ2222@piout.net> References: <1455995444-14146-1-git-send-email-alexandre.belloni@free-electrons.com> <20160220194310.02964d5f@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160220194310.02964d5f@lxorguk.ukuu.org.uk> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 20/02/2016 at 19:43:10 +0000, One Thousand Gnomes wrote : > On Sat, 20 Feb 2016 20:10:44 +0100 > Alexandre Belloni 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