linux-kernel - Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 29 Nov 2015 22:30:39 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Theodore Ts'o <tytso@....edu>
Cc:	David Howells <dhowells@...hat.com>, linux-afs@...r.kernel.org,
	linux-nfs@...r.kernel.org, linux-cifs@...r.kernel.org,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, linux-ext4@...r.kernel.org,
	Deepa Dinamani <deepa.kernel@...il.com>
Subject: Re: [PATCH 01/12] Ext4: Fix extended timestamp encoding and decoding

On Saturday 28 November 2015 21:45:55 Theodore Ts'o wrote:
> On Tue, Nov 24, 2015 at 09:10:53PM +0100, Arnd Bergmann wrote:
> > On Tuesday 24 November 2015 14:36:46 Theodore Ts'o wrote:
> > > This is the patch I would prefer to use (and in fact which I have
> > > added to the ext4 tree):
> > > 
> > > There are issues with 32-bit vs 64-bit encoding of times before
> > > January 1, 1970, which are handled with this patch which is not
> > > handled with what you have in your patch series.  So I'd prefer if you
> > > drop this patch, and I'll get this sent to Linus as a bug fix for 4.4.
> > 
> > I'm happy with either one. Apparently both Davids have arrived with
> > almost the same algorithm and implementation, with the exception of
> > the pre-1970 handling you mention there.
> 
> I was doing some testing on x86, which leads me to ask --- what's the
> current thinking about post y2038 on 32-bit platforms such as x86?  I
> see that there was some talk about using struct timespec64, but we
> haven't made the transition in the VFS interfaces yet, despite a
> comment in an LWN article from 2014 stating that "the first steps have
> been taken; hopefully the rest will follow before too long".

The approach in my initial VFS series was to introduce 'struct inode_time',
but I have basically abandoned that idea now, after we decided to introduce
'timespec64' inside of the kernel and use that for other subsystems.
The rought plan is now to have separate time64_t and u32 seconds/nanoseconds
values in 'struct inode', 'struct iattr' and 'struct kstat' and use
inline functions or macros to extract or set them as time64_t or timespec64
in file system code, but that code is not written yet.

I'm mostly coordinating the y2038 work at the moment, but that means that
a lot of the work is going into individual drivers that a single person
can easily handle. We've had a couple of people who tried looking at VFS,
but none of them followed through, so it got delayed a bit. However,
Deepa Dinamani is now looking y2038 for VFS and individual file systems
as part of her Outreachy internship and I'm optimistic that we'll soon
be making progress again here with her work.

The other large missing piece is the system call implementation. I have
posted a series earlier this year before my parental leave, and it's
currently lacking review from libc folks, and blocked on me to update
the series and post it again.

	Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/