From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759578AbcBTWRf (ORCPT ); Sat, 20 Feb 2016 17:17:35 -0500 Received: from mout.kundenserver.de ([212.227.126.131]:54470 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759529AbcBTWRa (ORCPT ); Sat, 20 Feb 2016 17:17:30 -0500 From: Arnd Bergmann To: Alexandre Belloni Cc: One Thousand Gnomes , rtc-linux@googlegroups.com, Alessandro Zummo , Willy Tarreau , linux-kernel@vger.kernel.org Subject: Re: [PATCH] rtc: Add an option to invalidate dates in 2038 Date: Sat, 20 Feb 2016 23:16:48 +0100 Message-ID: <9634631.sIvUQESgNh@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160220204715.GJ2222@piout.net> References: <1455995444-14146-1-git-send-email-alexandre.belloni@free-electrons.com> <20160220194310.02964d5f@lxorguk.ukuu.org.uk> <20160220204715.GJ2222@piout.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:QKBP7KBywf8t1Jzx3Z5hn+BONbgyxQchZKeFSsZdzwus6ROeFyO huTs1oDdh/LoJVD2zJ2urnO76ieWh6CHZ9YVGfjhvdo6oGJG58fltGdOyNY0Y87pZNjrV0t z1DpfMxnjs2KP4nJ8vIJSBmzybgFhCrRD2m9FUcTXhjtqU0H2xF14iks0UOqmQcdSxAjguE e8d/82S/wraZVMboJujfA== X-UI-Out-Filterresults: notjunk:1;V01:K0:CFJ3cojpVDU=:TPHfLsEJrjPR4XTq0LS9Tv x5fz5KZYqIRmEWjGU2Fup1YRgoQktchNeqwq602hJrdmB6/nKiDF4+Ji+n0yFrDryW9k/kLqy FZI2ojTUMUmzCKSlj/jJFSytqgccmMkh7KjmiG0FUbC0KR/0mFxVHIwdpqwhx4tcV1/Qpq7yh TJV0K2LCASwd6R3Z7IGtWdMB3dcbuIGTm1ekZt5IutEuRELTJsI4aZOOIv3Ys7HUyDt4hD4eC UK2orF6X6REhXvxGghvKg9usEeNYZiOvz+VdC15fYDCBXp0WpwL7nWEndsJmi5pa4tBDDSwqR TZMiyRKblfGimFt17MBeXOj8wO0GP/JeeVFVBK4vFTNEioCIAHxgudlVwjLb+uYfdXmJZizm0 j2BUkp0CfkDoRHcgkSuR50BZnbNMVVy0e/vftMYF5jaAm9jrvZQ/YxZVn0qRWNszQF/1DlrKd zdRNJkEaEnDNwuQ2dUlIcdFlOZr7Z1f82zgkiX1n853corAY9Nt84OF/5FjJRcpyT7wdeKjDx HPpkO7601gzK7mMMkrzw8koMOECUTdcHrZwzApsfkmCGJlbO/tqbgwdZO1eQTSmW5IOOChyRD YL+fvHeDsMinIvJfUPvhVAukXhAO49JJIwtob4mbdF6HekNGCELpt62MggK9aCpI8lYuUNF5q tCitOhlicdDkOXOzZpK8EQwtYPCixAaaTimhao7C9Bk0J/wDnYpeEM89ndL/fMeC6klKDaH/j ZCZnfzAhhWPNksSP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 20 February 2016 21:47:15 Alexandre Belloni wrote: > > 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 > I think in both cases you introduce a new 2038 problem though: as long as you have a kernel that tries to support an old 32-bit systemd build, the kernel becomes incompatible with RTC times beyond 2038, even on 64-bit systems and 32-bit systems that have fixed system call table and fixed user space. This is bad because it means we still have to break systemd eventually in order to fix the 2038 overflow. The plan to revert this after glibc has been converted is problematic because a lot of 32-bit distros will likely never recompile with 64-bit time_t in order to avoid breaking backwards compatibility. While we could require that user space and kernel must match here (either support 64-bit time_t everywhere or nowhere), that makes it much harder to deal with the migration, and it has always been a strict requirement that none of the changes for y2038 compatibility break existing user space (which of course is what happened for RTC and what we need to fix here). Has the problem of random RTC times been observed on more than one RTC driver yet? Maybe we can just apply your workaround to that one driver that saw it instead. Have you figured out whether there is a pattern in the reported times? Is it just completely random or could we perhaps detect an RTC that reports an invalid time other than by looking at the year? Arnd