From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755074AbcBVQk5 (ORCPT ); Mon, 22 Feb 2016 11:40:57 -0500 Received: from down.free-electrons.com ([37.187.137.238]:39053 "EHLO mail.free-electrons.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753404AbcBVQkz (ORCPT ); Mon, 22 Feb 2016 11:40:55 -0500 Date: Mon, 22 Feb 2016 17:40:53 +0100 From: Alexandre Belloni To: Arnd Bergmann 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 Message-ID: <20160222164053.GQ2222@piout.net> References: <1455995444-14146-1-git-send-email-alexandre.belloni@free-electrons.com> <6269543.oe8MmZQUmX@wuerfel> <20160222155653.GP2222@piout.net> <2768647.1bFEcFDZRI@wuerfel> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2768647.1bFEcFDZRI@wuerfel> 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 22/02/2016 at 17:18:03 +0100, Arnd Bergmann wrote : > > > 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. > I'm not completely sure how this would be different from my current patch... > > 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. > I didn't check other distribution but debian and poky have /etc/init.d/hwclock.sh that reads the rtc and sets the system time at startup. It also saves the time to the RTC on shutdown. -- Alexandre Belloni, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com