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: <20140603213802.GH14410@dastard>
Date:	Wed, 4 Jun 2014 07:38:02 +1000
From:	Dave Chinner <david@...morbit.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	"Joseph S. Myers" <joseph@...esourcery.com>,
	linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org,
	john.stultz@...aro.org, hch@...radead.org, tglx@...utronix.de,
	geert@...ux-m68k.org, lftan@...era.com,
	linux-fsdevel@...r.kernel.org, ceph-devel@...r.kernel.org,
	cluster-devel@...hat.com, coda@...cmu.edu,
	codalist@...emann.coda.cs.cmu.edu,
	fuse-devel@...ts.sourceforge.net, linux-afs@...ts.infradead.org,
	linux-btrfs@...r.kernel.org, linux-cifs@...r.kernel.org,
	linux-ext4@...r.kernel.org, linux-f2fs-devel@...ts.sourceforge.net,
	linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
	linux-ntfs-dev@...ts.sourceforge.net, linux-scsi@...r.kernel.org,
	logfs@...fs.org, ocfs2-devel@....oracle.com,
	reiserfs-devel@...r.kernel.org, samba-technical@...ts.samba.org,
	xfs@....sgi.com
Subject: Re: [RFC 00/32] making inode time stamps y2038 ready

On Tue, Jun 03, 2014 at 04:22:19PM +0200, Arnd Bergmann wrote:
> On Monday 02 June 2014 14:57:26 H. Peter Anvin wrote:
> > On 06/02/2014 12:55 PM, Arnd Bergmann wrote:
> The possible uses I can see for non-ktime_t types in the kernel are:
> * inodes need 96 bit timestamps to represent the full range of values
>   that can be stored in a file system, you made a convincing argument
>   for that. Almost everything else can fit into 64 bit on a 32-bit
>   kernel, in theory also on a 64-bit kernel if we want that.

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.

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

Cheers,

Dave.
-- 
Dave Chinner
david@...morbit.com
--
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/