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.