From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Date: Sun, 29 Nov 2015 22:30:39 +0100 Message-ID: <2872067.shHdUXoF07@wuerfel> References: <20151120145422.18930.72662.stgit@warthog.procyon.org.uk> <3495329.crWmoA5ACn@wuerfel> <20151129024555.GA31968@thunk.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: David Howells , linux-afs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-nfs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-cifs-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, samba-technical-w/Ol4Ecudpl8XjKLYN78aQ@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-fsdevel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-ext4-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Deepa Dinamani To: Theodore Ts'o Return-path: In-Reply-To: <20151129024555.GA31968-AKGzg7BKzIDYtjvyW6yDsg@public.gmane.org> Sender: linux-cifs-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: On Saturday 28 November 2015 21:45:55 Theodore Ts'o wrote: > On Tue, Nov 24, 2015 at 09:10:53PM +0100, Arnd Bergmann wrote: > > On Tuesday 24 November 2015 14:36:46 Theodore Ts'o wrote: > > > This is the patch I would prefer to use (and in fact which I have > > > added to the ext4 tree): > > > > > > There are issues with 32-bit vs 64-bit encoding of times before > > > January 1, 1970, which are handled with this patch which is not > > > handled with what you have in your patch series. So I'd prefer if you > > > drop this patch, and I'll get this sent to Linus as a bug fix for 4.4. > > > > I'm happy with either one. Apparently both Davids have arrived with > > almost the same algorithm and implementation, with the exception of > > the pre-1970 handling you mention there. > > I was doing some testing on x86, which leads me to ask --- what's the > current thinking about post y2038 on 32-bit platforms such as x86? I > see that there was some talk about using struct timespec64, but we > haven't made the transition in the VFS interfaces yet, despite a > comment in an LWN article from 2014 stating that "the first steps have > been taken; hopefully the rest will follow before too long". The approach in my initial VFS series was to introduce 'struct inode_time', but I have basically abandoned that idea now, after we decided to introduce 'timespec64' inside of the kernel and use that for other subsystems. The rought plan is now to have separate time64_t and u32 seconds/nanoseconds values in 'struct inode', 'struct iattr' and 'struct kstat' and use inline functions or macros to extract or set them as time64_t or timespec64 in file system code, but that code is not written yet. I'm mostly coordinating the y2038 work at the moment, but that means that a lot of the work is going into individual drivers that a single person can easily handle. We've had a couple of people who tried looking at VFS, but none of them followed through, so it got delayed a bit. However, Deepa Dinamani is now looking y2038 for VFS and individual file systems as part of her Outreachy internship and I'm optimistic that we'll soon be making progress again here with her work. The other large missing piece is the system call implementation. I have posted a series earlier this year before my parental leave, and it's currently lacking review from libc folks, and blocked on me to update the series and post it again. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752932AbbK2VbD (ORCPT ); Sun, 29 Nov 2015 16:31:03 -0500 Received: from mout.kundenserver.de ([212.227.17.24]:52786 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752562AbbK2Va5 (ORCPT ); Sun, 29 Nov 2015 16:30:57 -0500 From: Arnd Bergmann To: "Theodore Ts'o" Cc: David Howells , linux-afs@vger.kernel.org, linux-nfs@vger.kernel.org, linux-cifs@vger.kernel.org, samba-technical@lists.samba.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, Deepa Dinamani Subject: Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding Date: Sun, 29 Nov 2015 22:30:39 +0100 Message-ID: <2872067.shHdUXoF07@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <20151129024555.GA31968@thunk.org> References: <20151120145422.18930.72662.stgit@warthog.procyon.org.uk> <3495329.crWmoA5ACn@wuerfel> <20151129024555.GA31968@thunk.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:2PGqn2T3iriJo+zkGp4XTgWEvWkKgVVNOeRs9Dy46rAnAA3vzO2 ycD0oM5mTPyb82lMyWBFj3mjyoUnuVWUr7iPZCZ97VvCdhYVoHCXRZVJWpLdO9njmUABEsU XZagKk/7tjU/DhdCnIhfvKPawu+/4nkCk2k8JgrWY4NLIb1AeBCnY2r7DydOP2HbMotH/uF 6RvzJx0/D3aQ2Li+4UAIA== X-UI-Out-Filterresults: notjunk:1;V01:K0:mNtJ9Th+ZMM=:VuMjXgNsDEj9edQP8Tf7o7 pQPQtTdPjLaqS9HTBJ7PzKmlq3IxnGVDLCC9PjZuoZT4OEDSeHpzsn/BgfkWh+a5kjlA9rv3W gVJ+m/qODzX6EEVnTs+F2TGVvddPkfdpJ4UbOjKbP8ilkyEjOlyKMdNMMgCjoGgyhnzzrzSKx vDvswXtiVNc6BkTHxOWFueh8o2m1y2al8qO2qvJq2cNy24BDGppeLi+h+awQW+eZ9FPYRUxuy XiB7ukAYOJ8NZWrsMHWDb39A3eueJ+gxJgeo2Ke3ZWqAqb1JzR7pZrRA1RkRTZ1Y7alq4Mm+i IyLYD9+mK8pHED87QBtIUXOsjHEM+qvGqlzqGRqBKR64qQr1icpNU2jrLmW8ZkUYL72k/QEdb 5OwsAuqsfcSALF1pHGSZpLydukUAqjoqS8CpI+PFIIVWC1KF5sBhKqoQ547Tryn+Di2JiFT6h 7acUuSHL9lV1iw3oKmI3hz9ow1UFQUekkyXvSMl8++gqArhtgtQmfhBTDs/6e4B3SYzrtXH59 OvWgmCxHTd5aZt+6VaPHgXYyKRuGHPq+yUFXvZvsb88a8ncU12/vWOhKFaGQyzBTuO7DYjNSI we3Mbvvu8j0d0EEZrhcMlA50Lc9Hm4ijytj0rYHcj7wzUw55kJ2j8rdclwkJRRywRKfGrb6rt dMFk/QnoiyeZ4U9z7fCbI36dSSH4eiUYc9Ac+lewqDKZoLmTQU/wvFk3wQ9ZD0Qs2Hq+vEOqi yp2Toc2laf2n4ZBl Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Saturday 28 November 2015 21:45:55 Theodore Ts'o wrote: > On Tue, Nov 24, 2015 at 09:10:53PM +0100, Arnd Bergmann wrote: > > On Tuesday 24 November 2015 14:36:46 Theodore Ts'o wrote: > > > This is the patch I would prefer to use (and in fact which I have > > > added to the ext4 tree): > > > > > > There are issues with 32-bit vs 64-bit encoding of times before > > > January 1, 1970, which are handled with this patch which is not > > > handled with what you have in your patch series. So I'd prefer if you > > > drop this patch, and I'll get this sent to Linus as a bug fix for 4.4. > > > > I'm happy with either one. Apparently both Davids have arrived with > > almost the same algorithm and implementation, with the exception of > > the pre-1970 handling you mention there. > > I was doing some testing on x86, which leads me to ask --- what's the > current thinking about post y2038 on 32-bit platforms such as x86? I > see that there was some talk about using struct timespec64, but we > haven't made the transition in the VFS interfaces yet, despite a > comment in an LWN article from 2014 stating that "the first steps have > been taken; hopefully the rest will follow before too long". The approach in my initial VFS series was to introduce 'struct inode_time', but I have basically abandoned that idea now, after we decided to introduce 'timespec64' inside of the kernel and use that for other subsystems. The rought plan is now to have separate time64_t and u32 seconds/nanoseconds values in 'struct inode', 'struct iattr' and 'struct kstat' and use inline functions or macros to extract or set them as time64_t or timespec64 in file system code, but that code is not written yet. I'm mostly coordinating the y2038 work at the moment, but that means that a lot of the work is going into individual drivers that a single person can easily handle. We've had a couple of people who tried looking at VFS, but none of them followed through, so it got delayed a bit. However, Deepa Dinamani is now looking y2038 for VFS and individual file systems as part of her Outreachy internship and I'm optimistic that we'll soon be making progress again here with her work. The other large missing piece is the system call implementation. I have posted a series earlier this year before my parental leave, and it's currently lacking review from libc folks, and blocked on me to update the series and post it again. Arnd