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

[Dave Chinner <david@fromorbit.com>]

On Thu, Jan 14, 2016 at 11:54:36PM +0100, Arnd Bergmann wrote:
> On Thursday 14 January 2016 23:46:16 Arnd Bergmann wrote:
> > 
> > I'm not following the line of thought here. We have some users
> > that want ext4 to mount old file system images without long
> > inodes writable, because they don't care about the 2038 problem.
> > We also have other users that want to force the same file system
> > image to be read-only because they want to ensure that it does
> > not stop working correctly when the time overflow happens while
> > the fs is mounted.
> > 
> > If you don't want a compile-time option for it, how do you suggest
> > we decide which case we have?
> 
> In case that came across wrong, I'm assuming that the first
> user also wants all the system calls enabled that pass 32-bit
> time_t values, while the second one wants them all left out from
> the kernel to ensure that no user space program gets incorrect
> data.

system call API support is a completely different class of problem.
It's out of the scope of this patchset, and really I don't care what
you do with them.

The point I'm making is that we'll have to modify all the existing
filesystem code to supply a valid timestamp range to the VFS at
mount time for the range checking/clamping, similar to how we do the
granularity specification right now. That means we can do rejection
of non-y2038k compliant filesystems at runtime based on what the
filesystem tells the VFS it supports..  Set up the default to be
reject if rw, allow if ro, and provide a mount option to override ad
allow mounting rw.

Users can then make the decision when mounting their filesystems.
If they are system/automatically mounted filesystems and aren't
y2038k compliant, then the override option can be added to
/etc/fstab and we're all good. If the truly paranoid users want to
disallow the override and/or read only mount options, then add a
sysctl to control that.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com