linux-kernel - Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals

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 for Android: free password hash cracker in your pocket

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

Date:	Fri, 12 Feb 2016 15:03:46 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	y2038@...ts.linaro.org
Cc:	Deepa Dinamani <deepa.kernel@...il.com>,
	linux-fsdevel@...r.kernel.org, david@...morbit.com,
	' Theodore Ts'''o <tytso@....edu>,
	linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [RFC v2] vfs 64 bit time transition proposals

On Friday 12 February 2016 01:21:59 Deepa Dinamani wrote:
> Introduction
> 
> This is a follow on to the series: https://lkml.org/lkml/2016/1/7/20 [1].
> This is aimed at reaching a consensus on how to transition the vfs
> timestamps to use 64 bit time. This demonstrates three ways (2a, 2b and
> 2c) of solving this problem.  Each of the proposals has its own cover
> letter that explains the individual approach.  Proposals 2b and 2c also
> outline variant approaches which are similar to the respective proposals.
> This drives the proposal count to 5.  All the changes have been discussed
> with Arnd Bergmann, who posted the original series:
> https://lkml.org/lkml/2014/5/30/669 [2]
> 
> The series has been simplified to include only the 64 bit timestamp
> changes as per Dave Chinner’s suggestion.
> 
> Motivation
> 
> The problem is how to change the vfs inode timestamps to use 64 bit
> times to overcome the 2038 problem.
> 
> Below table [3] gives an overview of the extent/ type of changes
> needed of changes needed.
> The series is aimed at obtaining small manageable patches for all
> the cases in [3].
> 

Hi Deepa,

Thanks a lot for posting this updated series, very nice work!

Regarding the three versions, I think all of them are doable
doable, and they all have their upsides and downsides but no
showstoppers.

Let me summarize what I see in the patches:

2a is the smallest set of changes in number of lines, as you indicated
   in the previous discussion (I was skeptical here initially, but
   you were right). The main downside is that each patch has to
   carefully consider what happens at the point when the type gets
   flipped, so that printk format strings are correct and assignments
   to local variables don't truncate the range. It also requires
   changing the types again after the VFS change, but that is
   something we can automate using coccinelle.

2b has the main advantage of not changing behavior with the flip, so
   we can convert all file systems to use vfs_time relatively easily
   and then later make them actually use 64-bit timestamps with
   a patch that each file system developer can do for themselves.
   One downside is that it leads to rather ugly code as discussed
   before, examples are in "[RFC v2b 5/5] fs: xfs: change inode
   times to use vfs_time data type" and "[RFC v2b 3/5] fs: btrfs:
   Use vfs_time accessors".

2c gets us the furthest along the way for the conversion, close
   to where we want to end up in the long run, so we could do that
   to file systems one by one. The behavior change is immediate,
   so there are fewer possible surprises than with 2a, but it
   also means the most upfront work.

	Arnd