From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754368AbbJGNr1 (ORCPT ); Wed, 7 Oct 2015 09:47:27 -0400 Received: from mout.kundenserver.de ([212.227.126.187]:53260 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754345AbbJGNrZ (ORCPT ); Wed, 7 Oct 2015 09:47:25 -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 15:47:19 +0200 Message-ID: <5256796.UZaLfWxmcd@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1444224137-32510-1-git-send-email-mlichvar@redhat.com> References: <1444224137-32510-1-git-send-email-mlichvar@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:JkPv2pipuRP7hgpkB4s9DJrp0NQmprn+/T9xRS8JoIDReFZQ2zf HhqpriOgtwmabHWFquJBUMGNb1vWojgkWW3k7NPiLENTqprAdde4pKuQvfXdbbIFXx9dzdn 6S5QKBzYpGDqf2URthkHKSo1OAJxlTtR2sRcMr0DQyfKIe/ZTIiIXo8dgZw2LbAFpt1tpOL WN9Pk8x9uXj4DTkG3e1mQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:zk0UlMJW2IY=:2cGMSCPDX+peyHT+2rSkDB 7x0TegtNoDa8zZOXmxkhACvR8PW+H2cRlQY2ylPO/4+QdqUjTSyIfMwt1T1nT/K6zsGbhtZDC u6BuLes6mKvanTGUaUwmBDBGR1KIXRlQQ1d3+ZdgkONc5aGKYIZXDbZuEWZbeTLMR4e7n9VSu pARNp3aM9if3QjgHSusIwM6evUrLfHxC4IJaEGen/ME0YDMhzxOe15Dfo22Vmwn7glw+lAIZo G9b7qRvHE2EDhQlnno/LNyVjPwwdtBmKH/l+5jfvTo0bAL1vkpS7+tNAI7BFX7AwZkyfyYoy1 luN9VQsXgBUa7sRCr7VaoihwL6jMZUIHiCvPvNBuUPeRYkJHIoTifh35F4Vy7BFOjE+Wr5IwH FUonzQECHV2L4rGluunZgAtgALJ69oMb2bY8tRHICoIJXUwDoKMnpn83gQkTcxrUS5nr1O4cE DxGWph4lU4JTGWmZmukPAA0lyjczn+2D52zpmlquDr8mE5oZcl5w52c4z0ikjxLR40ifiCjNT JO7qeD62NPCx05KxsulhVvNf0NAKpEJK5x9QrgyCREWdDhNajvcCEBmmZVREvYRM9s4MlHR/u BfrkC2tSMRWBB8Wi8mqYmaaaUnCHhI1370TeeCXoK8tEdTHCY2LFn7bPFT3HKvH60SL3AWKKJ 8vv+sggkLXYhtnDTd3/7iF91YRlFnNeCJwDyldpgzsUaiiI0J8+I+zuzxu4sa7CCM5FGfYnxj Yj+0Xj/ufS6v82ou Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday 07 October 2015 15:22:17 Miroslav Lichvar wrote: > On systems with 32-bit time_t there are quite a few problems that > applications may have with time overflowing in year 2038. Beside getting > to an unexpected state by not checking integer operations with time_t > variables, some system calls have unexpected behavior, e.g. the system > time can't be set back to the current time (negative value), timers with > the ABSTIME flag can't be set (negative value) or they expire > immediately (current time is always larger). > > It would be unrealistic to expect all applications to be able to handle > all these problems. Year 2038 is still many years away, but this can be > a problem even now. The clock can get close to the overflow accidentally > or maliciously, e.g. when it is synchronized over network by NTP or PTP. > > 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. > > A new kernel sysctl time_max is added to select the maximum time. It can > be set to 0 for no limit, 1 for one week before 32-bit time_t overflow, > and 2 for one week before ktime_t overflow. The default value is 1 with > 32-bit time_t and 2 with 64-bit time_t. This can be changed later to be > always 2 when 64-bit versions of system calls working with time_t are > available. 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 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. So for all I can tell, your patch only replaces one set of problems that happens at the time of the overflow with a different set of problems. Arnd