Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1310286 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit time Arnd Bergmann <arnd@arndb.de> - 2016-01-15 18:10 +0100
    Re: [Y2038] [RFC 02/15] vfs: Change all structures to support 64 bit  time Dave Chinner <david@fromorbit.com> - 2016-01-15 23:50 +0100

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

On Friday 15 January 2016 13:27:34 Dave Chinner wrote:
> 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.

Sure, I was just providing some background about why we want a
compile-time option in general.

> 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.

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.

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. 

	Arnd

[toc] | [next] | [standalone]

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

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@fromorbit.com

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web