From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965155AbcBCVax (ORCPT ); Wed, 3 Feb 2016 16:30:53 -0500 Received: from mout.kundenserver.de ([212.227.126.134]:52150 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933982AbcBCVav (ORCPT ); Wed, 3 Feb 2016 16:30:51 -0500 From: Arnd Bergmann To: y2038@lists.linaro.org Cc: Deepa Dinamani , linux-fsdevel@vger.kernel.org, "Theodore Ts'o" , Dave Chinner , linux-kernel@vger.kernel.org Subject: Re: [Y2038] [PATCH 00/10] Remove CURRENT_TIME and CURRENT_TIME_SEC - PART 1 Date: Wed, 03 Feb 2016 22:30:44 +0100 Message-ID: <4775421.bkqoN6rOXc@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <1454479670-8204-1-git-send-email-deepa.kernel@gmail.com> References: <1454479670-8204-1-git-send-email-deepa.kernel@gmail.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:Lpd6OPvItGqk3TkzoPr7rGR45UDlywDpSxTRUaXGTXRiHmG15TQ 88dYYLHoyTg53OmqN72ordIbMh8wU8koD3NnueDcWpMKG2dLn9B6FAfuR0IPk5gnawB8ZBt 9lyuAqJrYlyQsWeR8COjvGsLDRVKnUsvtBCQEkw/rcIFwfHgc5++fuh99dWmaPn22PWocK9 kRfxz3SR3XbfaQQZ9PIOg== X-UI-Out-Filterresults: notjunk:1;V01:K0:ZQiMmErr29s=:gr43UAMY+tWFUQT7xTNhgJ RUYBqc2IRvHjIeyxCVQl7fWxzoyUlca36+M48aNA3XnTeFb7fEdINyixVofCh5WbgZDP729Om 6eZNS2YTuo2XTEen5YtQEdLqjYDeNShR1WeonaxSmgbXbFgSWQ/3SXB1VtLl31kLMIZvTlTlf n4nLh1qt/+nOPAmxptEIJuY2Fccu/z4JTT2QXFOrPu/Qol5YnGIHI6P+Xvjq5CWaxy2iKinjg L7N4Ks9VSxtQWkWsLQab7vnuq1xzOmVGRcu5g3BjDEu7K75bZtUeOvm/Bme2FcGxkwlf8qhLD WY7WQh2i9HWDv8PX35C+XK07ms2QkRju+W+RDM2L+nuB5iuj0IU8ue/RFMvQCqb3SIHrPE1Fq HXwlN9nhUf0fSztj3n377jTdO1L1VqYWNUZxDxSrTpyqJIvRFYck6KjrCXJkek7mbocYRVouj gdi5TS+SXtfrD+22XnEYvJv37Q0HGHWQ4JRYzyVSPRQVG6wkCdP3gvJqOJfM5jsKcU7zbGE/o e5BfyLZ77EAUwxWXF7bqRfe1tpbbzNn2CmOm9oH0jirZOMTzTwc+OKt96WCmWKeS/WH6KgP/Y TNoLUSmL0RbuV5m/ZB0Fvogga18YNwMB74AqysRlVXmDtppkZOUjqNB01290udGzA+dRAAlTF 1FewVd8aolkPARqun07ZMdy2y0NIdhkdYk6haw39Sr5cGxFlSM4oaSHL3FOvGTebJ7H77ZlrR WpnSGYyLBISf+3TfI6YFLbUL9zHuvNvyAubJvUmYePoQPVPoxpP2+Guwkp6aainx2WGrMYgrL vvp4OcwyZdyCBAReKjYHDSbE5pveA== Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tuesday 02 February 2016 22:07:40 Deepa Dinamani wrote: > This patch series is aimed at getting rid of CURRENT_TIME and CURRENT_TIME_SEC > macros. > > The idea for the series evolved from my discussions with Arnd Bergmann. > > This was originally part of the RFC series[2]: > https://lkml.org/lkml/2016/1/7/20 (under discussion). > > Dave Chinner suggested moving bug fixes out of the feature series to keep the > original series simple. > > There are 354 occurrences of the the above macros in the kernel. > The series will be divided into 4 or 5 parts to keep the parts manageable > and so that each part could be reviewed and merged independently. > This is part 1 of the series. Looks very nice to me. > Motivation > > The macros: CURRENT_TIME and CURRENT_TIME_SEC are primarily used for > filesystem timestamps. > But, they are not accurate as they do not perform clamping according to > filesystem timestamps ranges, nor do they truncate the nanoseconds value > to the granularity as required by the filesystem. > > The series is also viewed as an ancillary to another upcoming series[2] > that attempts to transition file system timestamps to use 64 bit time to > make these y2038 safe. > > There will also be another series[3] to add range checks and clamping to > filesystem time functions that are meant to substitute the above macros. > > Solution > > CURRENT_TIME macro has an equivalent function: > > struct timespec current_fs_time(struct super_block *sb) > > These will be the changes to the above function: > 1. Function will return the type y2038 safe timespec64 in [2]. > 2. Function will use y2038 safe 64 bit functions in [2]. > 3. Function will be extended to perform range checks in [3]. I guess [2] and [3] are really independent of one another and can be done in either order, correct? [2] will help to make 32-bit kernels work correctly on file systems that already support 64-bit timestamps internally, while [3] helps sanitize the behavior of file systems that cannot support that and that otherwise behave in unexpected ways on both 32-bit and 64-bit architectures. Arnd