linux-kernel - Re: [RFC 01/32] fs: introduce new 'struct inode

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: <53899AEA.1010909@zytor.com>
Date:	Sat, 31 May 2014 02:03:38 -0700
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org
CC:	linux-arch@...r.kernel.org, joseph@...esourcery.com,
	john.stultz@...aro.org, hch@...radead.org, tglx@...utronix.de,
	geert@...ux-m68k.org, lftan@...era.com,
	linux-fsdevel@...r.kernel.org
Subject: Re: [RFC 01/32] fs: introduce new 'struct inode_time'

On 05/30/2014 01:01 PM, Arnd Bergmann wrote:
> +#ifdef CONFIG_NEW_INODE_TIME
> +/*
> + * This is the type we use internally in the kernel to represent
> + * absolute times in file system metadata.
> + * This structure must not leak out to user space, and new interfaces
> + * should be using 64-bit types right away.
> + */
> +
> +/*
> + * Variant a) using unsigned seconds lets us extend the life span
> + * for another 69 years beyond 2038.
> + */
> +struct inode_time {
> +	unsigned long	tv_sec;
> +	long		tv_nsec;
> +};

This now differs between 32- and 64-bit systems, and on 32-bit systems
some timestamps well within the range of representation of current
systems just became unrepresentable, which is something that I thought
people were objecting very strongly to.

> +#elif 0
> +/*
> + * This variant can represent the widest range of times, but also
> + * bloats 'struct inode' a little more.
> + */
> +struct inode_time {
> +	long long	tv_sec __attribute__((packed));
> +	int		tv_nsec;
> +};

Seriously, though, can we really impose constraints stricter than what
the filesystems themselves do?  It seems we ought to be able to
represent whatever time the filesystem can represent... (modulo some
kind of window control as Y2038 or any other break point approaches.)

	-hpa




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