linux-kernel - Re: [Y2038] [RFC v2b 5/5] fs: xfs: change inode times to use vfs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4958737.lb1Wz85Yzh@wuerfel>
Date:	Sat, 13 Feb 2016 15:50:58 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	y2038@...ts.linaro.org
Cc:	Dave Chinner <david@...morbit.com>,
	Deepa Dinamani <deepa.kernel@...il.com>,
	linux-fsdevel@...r.kernel.org, Theodore Ts'o <tytso@....edu>,
	linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [RFC v2b 5/5] fs: xfs: change inode times to use vfs_time data type

On Saturday 13 February 2016 13:18:32 Dave Chinner wrote:
> On Fri, Feb 12, 2016 at 01:45:49AM -0800, Deepa Dinamani wrote:
> > This is in preparation for changing VFS inode timestamps to
> > use 64 bit time.
> > The VFS inode timestamps are not y2038 safe as they use
> > struct timespec. These will be changed to use struct timespec64
> > instead and that is y2038 safe.
> > But, since the above data type conversion will break the
> > end file systems, use vfs_time functions to access inode times.
> > 
> > current_fs_time() will change along with vfs timestamp data
> > type changes.
> > 
> > xfs_vn_update_time() is a .update callback for inode operations
> > and this needs to change along with vfs inode times.
> 
> This code is all different in the current XFS for-next branch.
> XFS no longer has it's own internal timestamps - it only uses the
> timestamps in the struct inode now.

Right, but as far as I can tell, this changes only contexts
for variants 2a and 2c, and makes patch 2b a few lines shorter
but does not impact whether any of the three approaches is
workable or not.

As you had some strong opinions on v1 of the series, could
you take a look at the three variants of v2 and say if you
have any preferences? It would be nice to agree on one approach
so we can merge that patch 1/xx as soon as possible and start
merging and adding further patches for the remaining file systems
so we can eventually get to the interface change.

	Arnd