From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de (mout.kundenserver.de. [217.72.192.74]) by gmr-mx.google.com with ESMTPS id v197si859831wmv.1.2016.02.22.08.18.07 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Feb 2016 08:18:07 -0800 (PST) From: Arnd Bergmann To: Alexandre Belloni Cc: One Thousand Gnomes , rtc-linux@googlegroups.com, Alessandro Zummo , Willy Tarreau , linux-kernel@vger.kernel.org Subject: [rtc-linux] Re: [PATCH] rtc: Add an option to invalidate dates in 2038 Date: Mon, 22 Feb 2016 17:18:03 +0100 Message-ID: <2768647.1bFEcFDZRI@wuerfel> In-Reply-To: <20160222155653.GP2222@piout.net> References: <1455995444-14146-1-git-send-email-alexandre.belloni@free-electrons.com> <6269543.oe8MmZQUmX@wuerfel> <20160222155653.GP2222@piout.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Reply-To: rtc-linux@googlegroups.com List-ID: List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , On Monday 22 February 2016 16:56:53 Alexandre Belloni wrote: > On 22/02/2016 at 16:44:32 +0100, Arnd Bergmann wrote : > > On Monday 22 February 2016 13:43:19 One Thousand Gnomes wrote: > > > On Mon, 22 Feb 2016 14:00:14 +0100 > > > Alexandre Belloni wrote: > > > > I can also agree that systemd could be a bit more robust there but > > > > you'll have to convince Lennart... > > > > > > That's a systemd problem. If their code isn't robust then the > > > distributiosn will just have to keep patching it. > > > > > > The only problem that can actually be "fixed" is the case where it isn't > > > 2038 yet and the user has a scrambled RTC. In that case your init tools > > > need to be robust enough to handle the problem or use APIs that don't > > > break. The kernel can't actually "fix" this because it never knows > > > whether your userspace is sane or not. > > > > > > I'd argue btw that any code using timerfd_create with TFD_TIMER_ABSTIME > > > and passing it a value that wraps the range permitted by that time > > > representation *is* buggy. It's the applications responsibility to use > > > values that are within the defined behavioural range of the function. > > > > IIRC, the problem is that user space passes in TIME_T_MAX and the kernel > > is considering that to be in the past because the clock is set beyond 2038. > > > > I find it hard to blame user space for that, but I don't have a good > > idea for solving this either. > > > > In case of systemd, it is literally the first thing that runs on the kernel > > after booting, so we could fall back to setting the time to some known > > working state (1970 or 2016 or something), but that would be a rather > > bad default policy once the system has been running for a while. > > > > Also, how would you know that it is an invalid time, some RTC doesn't > provide that information. What I meant was encountering a time past the 2038 date, which is invalid as seen from current 32-bit user space, but not necessarily from the kernel. > One other workaround is to asked distributions > using systemd to stop using HCTOSYS so userspace would be responsible to > set the system time and in that case we won't have the 32/64 discrepancy. I'm missing a bit of background here. This seems like a fairly useful piece of infrastructure for the majority of the use cases (working RTC) How would the time get set when this is disabled? Is systemd able to read the rtc and write it back to the kernel? That could in fact be a nicer workaround for the problem, if it just does this before setting up the timerfd. Arnd -- -- You received this message because you are subscribed to "rtc-linux". Membership options at http://groups.google.com/group/rtc-linux . Please read http://groups.google.com/group/rtc-linux/web/checklist before submitting a driver. --- You received this message because you are subscribed to the Google Groups "rtc-linux" group. To unsubscribe from this group and stop receiving emails from it, send an email to rtc-linux+unsubscribe@googlegroups.com. For more options, visit https://groups.google.com/d/optout. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752697AbcBVQSm (ORCPT ); Mon, 22 Feb 2016 11:18:42 -0500 Received: from mout.kundenserver.de ([217.72.192.74]:51078 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752513AbcBVQSk (ORCPT ); Mon, 22 Feb 2016 11:18:40 -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: Mon, 22 Feb 2016 17:18:03 +0100 Message-ID: <2768647.1bFEcFDZRI@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160222155653.GP2222@piout.net> References: <1455995444-14146-1-git-send-email-alexandre.belloni@free-electrons.com> <6269543.oe8MmZQUmX@wuerfel> <20160222155653.GP2222@piout.net> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:NEZ2WwE6lL2Js/4aJ5Eywy2naj/ouWU/ng8ChY5WGNPK524Un88 CJ9SLodudxDhJ785ZycwtTQaI9QFzo84ST2QnGbZb5B9etEvK4ivM8EPxD4Nw5ocVT5CJ3C 3Hn2NN1u19F/uLMbM+Rn35jr2puW4dbEKRQPeNS1Ne14XrMB9+yeYK8jo2pZwKp3IYkNO6r Gpo0WBmytJbDhbKdAFstg== X-UI-Out-Filterresults: notjunk:1;V01:K0:1Ecn59FJg0o=:bwpHUEkhVmMMQunGQVZsca eBBQyaKcLiHlv7U443yMU1+u1vE76I6SFsc7Wa3ieeBoeybLmcg1GW4TmUcWLwsx1A6cf1HL5 y6T/FFidEVIKVEfa/vDn78dCwdBJuwLOxd+7O2bTX5hZJX7VuHnlp5l7ZI/cOyzVkuHBFVs9y rn8zT4U+lXYJzrAyHsNvjlkYtftc76p6MXBzghibzGy76YPnJ7+Nbb90ZzBWzaOWvNnoZEFYk JjMjaPVsdojMoE1hb/eHRXBtoHbtoaqsPbgtxx2yqeZm09E99S9JhLQ0mws99644YnSEV5ipU rZwc6ovGqy38huoEtSmGFuhBzTyHJfGiTHyFmdKJBiIfvaBo8Ga18OBj58ITQHBYQiAx9loL0 4w8ZMbcFkvUlse1wBQNAu+4XLijFR94u1iCImHjVsGmbJIMmg4w9G9ZWweB3xpOfE9G/BMo7v 4rdIGpZzdr2g32nw7F2vApe+RhVxgMYjzqnwjaXCy4i3YDt0UTr9rchMThCiAJH+JvgGiH/y3 L5AvI3Vq2bE8dmKCjxa511sMdcRoATe/GAaBuGEAdDYHfT4VxWqmyiDbHjZYnoK5YIES1Ome2 EdtyRz43ByE49SxOBLPN4zB4Y0rjSXEeWth4Wp1Xr6YGLLuuWVynnnvHTdeXRr5lmPZNU27HJ 6CNyrnudVT/FqeTkSJccRqMfg5y70p6XFC1FsGt6AeD0bj7ghvBBmkuhtmxI5RZTNQBa4V/pb E2KoMNSAKnhg5k3H Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 22 February 2016 16:56:53 Alexandre Belloni wrote: > On 22/02/2016 at 16:44:32 +0100, Arnd Bergmann wrote : > > On Monday 22 February 2016 13:43:19 One Thousand Gnomes wrote: > > > On Mon, 22 Feb 2016 14:00:14 +0100 > > > Alexandre Belloni wrote: > > > > I can also agree that systemd could be a bit more robust there but > > > > you'll have to convince Lennart... > > > > > > That's a systemd problem. If their code isn't robust then the > > > distributiosn will just have to keep patching it. > > > > > > The only problem that can actually be "fixed" is the case where it isn't > > > 2038 yet and the user has a scrambled RTC. In that case your init tools > > > need to be robust enough to handle the problem or use APIs that don't > > > break. The kernel can't actually "fix" this because it never knows > > > whether your userspace is sane or not. > > > > > > I'd argue btw that any code using timerfd_create with TFD_TIMER_ABSTIME > > > and passing it a value that wraps the range permitted by that time > > > representation *is* buggy. It's the applications responsibility to use > > > values that are within the defined behavioural range of the function. > > > > IIRC, the problem is that user space passes in TIME_T_MAX and the kernel > > is considering that to be in the past because the clock is set beyond 2038. > > > > I find it hard to blame user space for that, but I don't have a good > > idea for solving this either. > > > > In case of systemd, it is literally the first thing that runs on the kernel > > after booting, so we could fall back to setting the time to some known > > working state (1970 or 2016 or something), but that would be a rather > > bad default policy once the system has been running for a while. > > > > Also, how would you know that it is an invalid time, some RTC doesn't > provide that information. What I meant was encountering a time past the 2038 date, which is invalid as seen from current 32-bit user space, but not necessarily from the kernel. > One other workaround is to asked distributions > using systemd to stop using HCTOSYS so userspace would be responsible to > set the system time and in that case we won't have the 32/64 discrepancy. I'm missing a bit of background here. This seems like a fairly useful piece of infrastructure for the majority of the use cases (working RTC) How would the time get set when this is disabled? Is systemd able to read the rtc and write it back to the kernel? That could in fact be a nicer workaround for the problem, if it just does this before setting up the timerfd. Arnd