On Fri, Jan 15, 2016 at 06:01:36PM +0100, Arnd Bergmann wrote: > On Friday 15 January 2016 13:27:34 Dave Chinner wrote: > > 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. > > We can't really default to "reject if rw", because that would break > all systems using ext3 or xfs, unless users modify their fstab > or set the flag that makes the partition y2038 compliant. Right, I was refering to the behaviour of a y2038k compliant kernel, A current non-compliant kernel will have the default behaviour you are suggesting. > The compile-time option that I'm thinking of would change the default > beween "always allow" and "reject if rw", based on whether the > system cares about this issue or not. Almost everyone today won't > care about it at all and would be rather annoyed by being unable > to mount their rootfs, but some people care about the behavior > a lot. Yup, that's exactly what I was implying. > Having a global sysctl or mount option as an override would be good, > maybe both if that isn't over-engineering the problem when we already > have a compile-time option. Distros should not be forces to ship multiple kernels just to provide all the different runtime compliance behaviours their users require. Make the policy runtime enforcable, but select the default behaviour and supported policies via compile time options. 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
