Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time
From: Deepa Dinamani
Date: Thu Jan 14 2016 - 13:01:08 EST
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@xxxxxxxxxxxxx> 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().