From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754036AbcBVPpJ (ORCPT ); Mon, 22 Feb 2016 10:45:09 -0500 Received: from mout.kundenserver.de ([217.72.192.74]:59779 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752833AbcBVPpH (ORCPT ); Mon, 22 Feb 2016 10:45:07 -0500 From: Arnd Bergmann To: One Thousand Gnomes Cc: Alexandre Belloni , 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 16:44:32 +0100 Message-ID: <6269543.oe8MmZQUmX@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20160222134319.31e77b71@lxorguk.ukuu.org.uk> References: <1455995444-14146-1-git-send-email-alexandre.belloni@free-electrons.com> <20160222130014.GN2222@piout.net> <20160222134319.31e77b71@lxorguk.ukuu.org.uk> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:UUrGG+6iyv+3INUlgNMtDorx1yUO5rPl4Z3E7mZSxZQo8LyuW4S WKGNFLsSkJ1Eua1sY07wHKbhqAxcgKUHKGeFM9KVpZO6V/6pE51LqfBU+OunaWFYT1WACwN 4GU4NcxMPPXjEWOU4DG4Vxcx3SMnwYWXkaGX6QQ4fc4Sd+AxDeospSr6/g9W66NxgPfsOEB eh1rUnTW6DiCBCp20wJkA== X-UI-Out-Filterresults: notjunk:1;V01:K0:DKypDQv65kU=:/YnEswqg+S9igu2ek5vxSw dVG1jFp0phrBx34/m8iSflb1NQJdy3EcgsxYxKd1PMtsYMtgW3cTmMd2XFA6KtvDYGCQ3JbDm rRhdnnRIG1BuiVSwr7Y8H3aUc22Q8pMKa6AsZ0QZbsc2PNVrBzuNBYiYHgL0yAQRB2AzOQufn S0P0eV+15+YFOKpEKQchiPhtupSDNfgpjcGQZnR2erDyVfSTwJ1h3XUWabTf/mnIfizIx7Ud7 88nUtos1JumTOI2HDIP0qkICt/5z1yt7Xn2EH85d3Mlk/sN4YfrWzljn32fY3Z9PZA+It0XAF 7T1gGhKKh5v+3ghz49tXOMgaHPIUiPUQUm5VuJcQTvoPUWvWMSy/vr38aPURI3dcXGBqbBTTl rwo6GzyIoGTTh66+MgkTVyzuuTuEY5aHp849I6+aJnUjhMPhIWPzEtux/xmNCD25DPW6PDnDx SsnZeTZzIvnBmpUPLuAig7EruSvM0dUEVmaveD5+wYnlE/qz1HUSehZqqI895XzzXbb7iomCP ZWx5lIzEX+v1Vx2GMS49+u1kfGTGhu6dXPJ4rV3rHvTO3cey02iyjNNqzPy+63pioXckANLxx rlFsMwNW0UoIvByCQgxXLOGsHomQ2NwShPiAQd9pyykZzN0A1WWtk7oy/iN+y0/UXaTgWwkti 3RH3biGY0Huz2aGF30zoHI4vl+vGV6kivRUNEgnZ41OxDkUNsdVcaUlUzde8jQKopQulAv+zG Q5gRpxOIrcBNg3d8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. The best we can do for a workaround localized to timerfd might be to make absolute timers behave differently when they come from a 32-bit process and the current time has already overflown. > Far more constructive would I think be to add a TFD_TIME64 flag to > timerfd_create that allows the use of 64bit time in timerfd_*. Systemd > can then adopt that safely even on 32bit legacy systems, while on 64bit > TFD_TIME64 would presumably be 0 and the 64/32bit time structs would > match. I should really dust off my syscall series, I'd rather not have any partial solutions to merged here. Arnd