linux-kernel - Re: [PATCH 00/25] Change time_t and clock

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:	Tue, 13 May 2014 10:46:40 -0700
From:	Christoph Hellwig <hch@...radead.org>
To:	Thomas Gleixner <tglx@...utronix.de>
Cc:	Ley Foon Tan <lftan@...era.com>, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org, lftan.linux@...il.com,
	cltang@...esourcery.com, Arnd Bergmann <arnd@...db.de>
Subject: Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

On Tue, May 13, 2014 at 05:33:01PM +0200, Thomas Gleixner wrote:
> Err, we CANNOT do that. We cannot move ANY 32 bit architecture to
> 64bit time_t without breaking the world and some more.

Of course we can, we just need to still provide the existing 32-bit
time_t ABIs for backwards compatiblity.  That's how we handled
extensions of other types like off_t in the past.

> All 64bit architectures use 64bit time_t already plus the x32 ABI of x86.

64-bit is not relevant for the pain as there time_t is simply a long,
while for 32-bit types we move to a longer than pointer sized type,
in direct contradiction to older standards the explicitly prohibit this.

> So why would user space explode? It did not explode with x32

Who knows?  It's not like x32 actually has any significant user base.
In fact just weeks ago we fixed fundamental type system bugs for it.

> and it
> would be dumb as hell to have new archs use time_t 32bit when we are
> currently twisting our brain around how to solve the y2038
> problem. Simply because we can not do the BSD flag day approach and
> change it.

I don't think it's a good idea to have minor new architectures
pointlessly different than the major ones.  Especially given that we'll
absolutely have to fir the y2038 problem for 32-bit arm and probably
x86 anyway.

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