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

2016-01-20 Thread Deepa Dinamani
On Tue, Jan 19, 2016 at 9:12 PM, Deepa Dinamani wrote: > > On Tue, Jan 19, 2016 at 2:25 PM, Arnd Bergmann wrote: >> On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote: >>> On Mon, Jan 18, 2016 at 09:27:13PM -0800, Deepa Dinamani wrote: >>> > On Mon,

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

2016-01-20 Thread Dave Chinner
On Tue, Jan 19, 2016 at 11:25:02PM +0100, Arnd Bergmann wrote: > On Wednesday 20 January 2016 07:49:46 Dave Chinner wrote: > > You're doing it wrong. fat_time_fat2unix() still gets passed > > >i_mtime, and the function prototype is changed to a > > timespec64. *Nothing else needs to change*,

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

2016-01-20 Thread Arnd Bergmann
On Thursday 21 January 2016 10:06:32 Dave Chinner wrote: > > IOWs, you're now finally suggesting doing the *simple conversion* > I've been suggesting needs to be made *since the start* of this > long, frustrating thread, except you *still want to abstract the > timestamp unnecessarily*. > > For

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

2016-01-19 Thread Dave Chinner
On Mon, Jan 18, 2016 at 09:27:13PM -0800, Deepa Dinamani wrote: > > > On Mon, Jan 18, 2016 at 5:38 PM, Dave Chinner wrote: > > On Mon, Jan 18, 2016 at 10:46:07PM +0100, Arnd Bergmann wrote: > >> On Tuesday 19 January 2016 08:14:59 Dave Chinner wrote: > >> > On Mon, Jan 18,

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

2016-01-18 Thread Deepa Dinamani
On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann wrote: > On Sunday 17 January 2016 22:09:26 Deepa Dinamani wrote: >> Based on the discussion, here is how I propose to proceed: >> >> 1. Series for timestamp range check and clamping >> 2. Bug fixing patches like change all

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

2016-01-18 Thread Arnd Bergmann
On Monday 18 January 2016 09:40:12 Deepa Dinamani wrote: > On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann wrote: > > On Sunday 17 January 2016 22:09:26 Deepa Dinamani wrote: > >> Based on the discussion, here is how I propose to proceed: > > Sounds good to me. Step 3 of course is

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

2016-01-18 Thread Dave Chinner
On Mon, Jan 18, 2016 at 10:46:07PM +0100, Arnd Bergmann wrote: > On Tuesday 19 January 2016 08:14:59 Dave Chinner wrote: > > On Mon, Jan 18, 2016 at 08:53:22PM +0100, Arnd Bergmann wrote: > > > 3. for each file system that uses struct timespec internally to pass > > >around inode timestamps,

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

2016-01-18 Thread Arnd Bergmann
On Tuesday 19 January 2016 08:14:59 Dave Chinner wrote: > On Mon, Jan 18, 2016 at 08:53:22PM +0100, Arnd Bergmann wrote: > > On Monday 18 January 2016 09:40:12 Deepa Dinamani wrote: > > > On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann wrote: > > > > I agree it's ugly and fragile

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

2016-01-18 Thread Dave Chinner
On Mon, Jan 18, 2016 at 08:53:22PM +0100, Arnd Bergmann wrote: > On Monday 18 January 2016 09:40:12 Deepa Dinamani wrote: > > On Mon, Jan 18, 2016 at 2:56 AM, Arnd Bergmann wrote: > > > On Sunday 17 January 2016 22:09:26 Deepa Dinamani wrote: > > >> Based on the discussion, here is

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

2016-01-17 Thread Deepa Dinamani
Based on the discussion, here is how I propose to proceed: 1. Series for timestamp range check and clamping 2. Bug fixing patches like change all CURRENT_TIME use cases to current_fs_time() 3. Patches for vfs to use timespec64 internally (maybe a series, if required) 4. Patches that change all

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

2016-01-16 Thread Arnd Bergmann
On Saturday 16 January 2016 12:14:22 Andreas Dilger wrote: > >> > >> Sure, and nfs is a pain because of all it's internal use of > >> timespecs, too. > > > > lustre is probably the worst. > > Lustre currently only has one-second granularity in a 64-bit field, > so it doesn't really care about

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

2016-01-15 Thread Arnd Bergmann
On Friday 15 January 2016 13:49:37 Dave Chinner wrote: > On Thu, Jan 14, 2016 at 11:46:16PM +0100, Arnd Bergmann wrote: > > On Friday 15 January 2016 08:00:01 Dave Chinner wrote: > > > On Thu, Jan 14, 2016 at 05:53:21PM +0100, Arnd Bergmann wrote: > > > > On Thursday 14 January 2016 08:04:36 Dave

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

2016-01-15 Thread Dave Chinner
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

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

2016-01-14 Thread Arnd Bergmann
On Thursday 14 January 2016 08:04:36 Dave Chinner wrote: > On Wed, Jan 13, 2016 at 08:33:16AM -0800, Deepa Dinamani wrote: > > On Tue, Jan 12, 2016 at 07:29:57PM +1100, Dave Chinner wrote: > > > On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote: > > > > > On Jan 11, 2016, at 04:33,

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

2016-01-13 Thread Arnd Bergmann
On Wednesday 13 January 2016 17:27:16 Dave Chinner wrote: > > I think > > it was more than that when I first looked, so it's between 0.2% and 0.3% > > of savings in total memory, which is certainly worth discussing about, > > given the renewed interest in conserving RAM in general. If we want to

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

2016-01-13 Thread Dave Chinner
On Wed, Jan 13, 2016 at 08:33:16AM -0800, Deepa Dinamani wrote: > On Tue, Jan 12, 2016 at 07:29:57PM +1100, Dave Chinner wrote: > > On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote: > > > > On Jan 11, 2016, at 04:33, Dave Chinner wrote: > > > > > > > >> On Wed,

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

2016-01-13 Thread Deepa Dinamani
On Tue, Jan 12, 2016 at 07:29:57PM +1100, Dave Chinner wrote: > On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote: > > > On Jan 11, 2016, at 04:33, Dave Chinner wrote: > > > > > >> On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote: Summarizing, here

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

2016-01-12 Thread Dave Chinner
On Tue, Jan 12, 2016 at 10:27:07AM +0100, Arnd Bergmann wrote: > On Tuesday 12 January 2016 19:29:57 Dave Chinner wrote: > > > > This is what I meant about premature optimisation - you've got a > > wonderfully complex solution to a problem that we don't need to > > solve to support timestamps

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

2016-01-12 Thread Dave Chinner
On Mon, Jan 11, 2016 at 09:42:36PM -0800, Deepa Dinamani wrote: > > On Jan 11, 2016, at 04:33, Dave Chinner wrote: > > > >> On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote: > >> The current representation of inode times in struct inode, struct iattr, > >> and

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

2016-01-11 Thread Deepa Dinamani
> On Jan 11, 2016, at 04:33, Dave Chinner wrote: > >> On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote: >> The current representation of inode times in struct inode, struct iattr, >> and struct kstat use struct timespec. timespec is not y2038 safe. >> >> Use

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

2016-01-10 Thread Dave Chinner
On Wed, Jan 06, 2016 at 09:35:59PM -0800, Deepa Dinamani wrote: > The current representation of inode times in struct inode, struct iattr, > and struct kstat use struct timespec. timespec is not y2038 safe. > > Use scalar data types (seconds and nanoseconds stored separately) to > represent