From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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> 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" Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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