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@xxxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
