linux-kernel - Re: [RFC 00/32] making inode time stamps y2038 ready

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]

Message-ID: <alpine.LFD.2.11.1406041308300.17310@knanqh.ubzr>
Date:	Wed, 4 Jun 2014 13:30:32 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	Arnd Bergmann <arnd@...db.de>
cc:	Dave Chinner <david@...morbit.com>, hch@...radead.org,
	linux-mtd@...ts.infradead.org, "H. Peter Anvin" <hpa@...or.com>,
	logfs@...fs.org, linux-afs@...ts.infradead.org,
	"Joseph S. Myers" <joseph@...esourcery.com>,
	linux-arch@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-scsi@...r.kernel.org, ceph-devel@...r.kernel.org,
	cluster-devel@...hat.com, coda@...cmu.edu, geert@...ux-m68k.org,
	linux-ext4@...r.kernel.org, codalist@...emann.coda.cs.cmu.edu,
	fuse-devel@...ts.sourceforge.net, reiserfs-devel@...r.kernel.org,
	xfs@....sgi.com, john.stultz@...aro.org, tglx@...utronix.de,
	linux-nfs@...r.kernel.org, linux-ntfs-dev@...ts.sourceforge.net,
	samba-technical@...ts.samba.org, linux-kernel@...r.kernel.org,
	linux-f2fs-devel@...ts.sourceforge.net, ocfs2-devel@....oracle.com,
	linux-fsdevel@...r.kernel.org, lftan@...era.com,
	linux-btrfs@...r.kernel.org
Subject: Re: [RFC 00/32] making inode time stamps y2038 ready

On Wed, 4 Jun 2014, Arnd Bergmann wrote:

> On Tuesday 03 June 2014, Dave Chinner wrote:
> > Just ot be pedantic, inodes don't need 96 bit timestamps - some
> > filesystems can *support up to* 96 bit timestamps. If the kernel
> > only supports 64 bit timestamps and that's all the kernel can
> > represent, then the upper bits of the 96 bit on-disk inode
> > timestamps simply remain zero.
> 
> I meant the reverse: since we have file systems that can store
> 96-bit timestamps when using 64-bit kernels, we need to extend
> 32-bit kernels to have the same internal representation so we
> can actually read those file systems correctly.
> 
> > If you move the filesystem between kernels with different time
> > ranges, then the filesystem needs to be able to tell the kernel what
> > it's supported range is.  This is where having the VFS limit the
> > range of supported timestamps is important: the limit is the
> > min(kernel range, filesystem range). This allows the filesystems
> > to be indepenent of the kernel time representation, and the kernel
> > to be independent of the physical filesystem time encoding....
> 
> I agree it makes sense to let the kernel know about the limits
> of the file system it accesses, but for the reverse, we're probably
> better off just making the kernel representation large enough (i.e.
> 96 bits) so it can work with any known file system.

Depends...  96 bit handling may get prohibitive on 32-bit archs.

The important point here is for the kernel to be able to represent the 
time _range_ used by any known filesystem, not necessarily the time 
_precision_.

For example, a 64 bit representation can be made of 40 bits for seconds 
spanning 34865 years, and 24 bits for fractional seconds providing 
precision down to 60 nanosecs.  That ought to be plenty good on 32 bit 
systems while still being cheap to handle.


Nicolas
--
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/