From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754658AbbJGPKu (ORCPT ); Wed, 7 Oct 2015 11:10:50 -0400 Received: from mout.kundenserver.de ([212.227.17.10]:53024 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753551AbbJGPKt (ORCPT ); Wed, 7 Oct 2015 11:10:49 -0400 From: Arnd Bergmann To: Miroslav Lichvar Cc: linux-kernel@vger.kernel.org, y2038@lists.linaro.org, John Stultz , Thomas Gleixner , Prarit Bhargava , Richard Cochran Subject: Re: [PATCH] timekeeping: Limit system time to prevent 32-bit time_t overflow Date: Wed, 07 Oct 2015 17:10:34 +0200 Message-ID: <5753784.UXVo9jVTVp@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151007142343.GM5778@localhost> References: <1444224137-32510-1-git-send-email-mlichvar@redhat.com> <5256796.UZaLfWxmcd@wuerfel> <20151007142343.GM5778@localhost> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:ODkYLyQ5ISUmuQYxOg5DAeHfVaqX1WELN9ZfTe4FwECYDhLzkxi xJ5f5zNSz4IdNTZukwj/3cs9X5Oo0d7wgVrUk/OpP6kSHLUN+PH5XUO76JZD0YL4PPzMkqx 4eC+RpihtIW5xlvNCoQAP64/AIwJmLBeW7YMKa5+9x80PYjcEgGc/536catYnV1A8v4/nlH bx8ArPbeLtSbiqr0VzzIg== X-UI-Out-Filterresults: notjunk:1;V01:K0:J0k6lQonhbc=:uDMoM6AyhZiGsLPUT9b0S/ hY7I2vdDcaCKX7oh6XcofDLA62pSYFrlyDdv7pJdkt7fVvbc9TfUxBgogkzxcdJM77+Env/5k GYdDPCBy75gnGkIj+mOnLpJNFn0MrwP2HcPtORCoPehf/8LsHgGR9NSRiIJ2s6CSlp9+fMxb6 y42MTW0J4v0zOaVDBbXdn7UeSwwaoXSKgrCZwprt2AzKNx2eEuBeCVULg8NBnzVirCdYyXWLW RSmq4mBXewe79Uw8didRpdZmb0l77+WIuc3SpMCf/cq6AqpL/Lx6aYW0sEVrZqIcJLj5rMgo/ HCKdxPmnSk8WhcGrCBydiI+KyYoyArUyxASQSonXMAV9Wcj2pb5RILp5cO70vIjLfP8yumxw1 A6T4QRUZ/YZv/HuZERSTSa29fX4X1jmhUDENDgEvk2hXu1SCbk2rHhpHSEuhmH7kqiWLvt2LC pIG9zMZrK2y6+FU5XI2mlc5/7cMgqrm5jbF2cYeR2PP6YZ7VqvsE58hjVZvgP2sR4vu3RR+6Z W2FZ48ETsWtcjwkqiorujuaPxMUybqT2EuWhAT2J7rLvsVTA2VBc2GdC66W85zok5cot/fgVp z473Bw3M57cE1NU6Zy47nQit2jU9ZwjiVonOJqGnpP9abbOQv4Y/o31MAdZYuSAU6tcHUKiff F/b264SJImgHGGERsH+6UUh3Q9XL5kyqAT7vGPm7HhjtnulzhlCWHmj36C1cWmpNQUdjucwBc hNZFqnE8aZHpB5AE Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 07 October 2015 16:23:44 Miroslav Lichvar wrote: > On Wed, Oct 07, 2015 at 03:47:19PM +0200, Arnd Bergmann wrote: > > On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote: > > > This patch sets a maximum value of the system time to prevent the system > > > time from getting too close to the overflow. The time can't be set to a > > > larger value. When the maximum is reached in normal time accumulation, > > > the clock will be stepped back by one week. > > > > I can't see whether this is really a good idea: moving the time backwards > > will break all sorts of drivers that (incorrectly) expect the real > > time clock to have monotonic behavior, and quite often, file timestamps > > Well, do these drivers break when the clock is stepped back by ntpd? Yes. > Maybe it would be better to fix them. We are in the process of doing that: All drivers that currently use do_gettimeofday() or get_seconds() are being audited and converted to one of ktime_get(), ktime_get_real(), ktime_get_ts64(), ktime_get_real_ts64(), ktime_get_seconds() or ktime_get_real_seconds(). The 'real' versions should only be used when the driver wants to know the wallclock but is ok with time going backwards. > > are expected to be in the past in user space. A common example is > > 'make', which goes nuts when it sees files in the future. > > Without the limit added by this patch make will go nuts just one week > later when the 32-bit time_t overflows to Dec 13 1901 and the files > will appear as 136 years in the future. How is that better? Not better or worse at all, that was my point. The time is still wrong either way, whether you step back by a week or 136 years. Arnd