From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.kundenserver.de ([212.227.126.133]:53025 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759989AbcCDQWI (ORCPT ); Fri, 4 Mar 2016 11:22:08 -0500 From: Arnd Bergmann To: Steve French Cc: y2038@lists.linaro.org, Dave Chinner , linux-fsdevel , Thomas Gleixner , Deepa Dinamani , Al Viro Subject: Re: [Y2038] [PATCH] vfs: Add support to check max and min inode times Date: Fri, 04 Mar 2016 17:21:52 +0100 Message-ID: <2036084.gnLX4sX4mL@wuerfel> In-Reply-To: References: <1456933894-17001-1-git-send-email-deepa.kernel@gmail.com> <5606621.WbB5EqEB2T@wuerfel> 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 Friday 04 March 2016 00:31:09 Steve French wrote: > >> i.e. 32 bit systems should default to 32 bit time limits until the > >> filesystem developers come along and verify that conversion from > >> their on-disk format to 64 bit time works correctly. Then they set > >> their real limits which may (or may not) be >y2038 compatible, and > >> this means that filesystems that have not been converted to >y2038 > >> compatible do not need any modifications to behave correctly on 32 > >> bit systems... > > > > We can set the limits in the superblock if you like, but I would > > not do it by changing the constants here: > > > > Most file systems have arbitrary other maximum dates that they > > need to set (on 64-bit systems), e.g. 2028 (iso9660), 2040 (hfsplus), > > 2106 (ceph), 2107 (fat, cifs), 2262 (logfs), 2514 (ext4). > > I am puzzled why 2107 would be the maximum date for cifs. My > calculation comes to a > maximum date of approximately the year 60,000AD for 64 bit DCE time > (cifs.ko gets DCE time back in all time fields when using CIFS, SMB2 or SMB3 > except for the oldest dialects of CIFS). DCE time is > 100 nanoseconds since 1601 - see the definition of FILETIME in section 2.3.3 > of https://msdn.microsoft.com/en-us/library/cc230324.aspx). And shouldn't > this be the same for NTFS as they use a similar DCE time internally? > The value I was looking up in my table at http://kernelnewbies.org/y2038 indeed referred to the ancient SMB timestamps that use a 7-bit year number starting in 1980, just as fat has. The year I have listed in the table for modern cifs and ntfs is 30328, which assumes that it's a signed 64-bit multiple of 100 nanoseconds, and that's what I see in cifs_NTtimeToUnix() as well. The documentation you point to describes it as unsigned, which matches your 60,000AD date, so before we add the limits, we should try to clarify which one was intended. Arnd