linux-kernel - Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time

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]

Date:	Thu, 14 Jan 2016 10:00:55 -0800
From:	Deepa Dinamani <deepa.kernel@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	y2038@...ts.linaro.org, Dave Chinner <david@...morbit.com>,
	Deepa Dinamani <deepa.kernel@...il.com>,
	linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit
 time

On Thu, Jan 14, 2016 at 05:53:21PM +0100, Arnd Bergmann wrote:
> On Thursday 14 January 2016 08:04:36 Dave Chinner wrote:
> > On Wed, Jan 13, 2016 at 08:33:16AM -0800, Deepa Dinamani wrote:
> > > On Tue, Jan 12, 2016 at 07:29:57PM +1100, Dave Chinner wrote:
> > > > On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote:
> > > > > > On Jan 11, 2016, at 04:33, Dave Chinner <david@...morbit.com> wrote:
> > > > > >> On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote:
> > >
> > > 2. How to achieve a seamless transition?
> > > 	Is inode_timespec solution agreed upon to achieve 1a?
> > 
> > No. Just convert direct to timespec64.
> 
> The hard part here is how to split that change into logical patches
> per file system. We have already discussed all sorts of ways to
> do that, but there is no ideal solution, as you usually end up
> either having some really large patches, or you have to modify
> the same lines multiple times.
> 
> The most promising approaches are:
> 
> a) In Deepa's current patch set, some infrastructure is first
>    introduced by changing the type from timespec to an identical
>    inode_timespec, which lets us convert one file system at a time
>    to inode_timespec and then change the type once they are all
>    done. The downside is then that all file systems have to get
>    touched twice so we end up with timespec64 everywhere.
> 
> b) A variation of that which I would do is to use have a smaller
>    set of infrastructure first, so we can change one file system
>    at a time to timespec64 while leaving the common structures to
>    use timespec until all file systems are converted. The downside
>    is the use of some conversion macros when accessing the times
>    in the inode.
>    When the common code is changed, those accessor macros get
>    turned into trivial assignments that can be removed up later
>    or changed in the same patch.
> 
> c) The opposite direction from b) is to first change the common
>    code, but then any direct assignment between a timespec in
>    a file system and the timespec64 in the inode/iattr/kstat/etc
>    first needs a conversion helper so we can build cleanly,
>    and then we do one file system at a time to remove them all
>    again while changing the internal structures in the
>    file system from timespec to timespec64.   

Just a clarification here:
approaches b and c also need some functions that take times as arguments,
including a function pointer in the vfs layer to be supported in both forms:
timespec and timespec64 concurrently.
As included in the cover letter, these are:
generic_update_time(), inode->i_op->update_time(), lease_get_mtime(),
fstack_copy_attr_all(), setattr_copy(), generic_fillattr().

-Deepa