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]

Message-ID: <alpine.LFD.2.11.1405142319140.17310@knanqh.ubzr>
Date:	Wed, 14 May 2014 23:32:29 -0400 (EDT)
From:	Nicolas Pitre <nicolas.pitre@...aro.org>
To:	"H. Peter Anvin" <hpa@...or.com>
cc:	John Stultz <john.stultz@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Christoph Hellwig <hch@...radead.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ley Foon Tan <lftan@...era.com>,
	Linux-Arch <linux-arch@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	LeyFoon Tan <lftan.linux@...il.com>,
	Chung-Lin Tang <cltang@...esourcery.com>
Subject: Re: [PATCH 00/25] Change time_t and clock_t to 64 bit

On Wed, 14 May 2014, H. Peter Anvin wrote:

> On 05/14/2014 02:33 PM, John Stultz wrote:
> > 
> > We can do some tricks for internal optimizations here if these are
> > critical.  I'd be more concerned about userland divisions where moving
> > to a 64bit time_t would cause performance issues that we cannot help
> > optimize.
> > 
> 
> Honestly, the cost of not addressing the Y2038 problem in plenty of time
> is going to be way, way, way, way more expensive than some additional
> arithmetic.
> 
> As far as converting to calendar notation (e.g. the Gregorian calendar),
> only the first division needs to be done with full time_t width.
> Furthermore, since the divisor is known a priori, the compiler *should*
> be able to do it as an inverse multiply.[1]

The compiler is apparently not that smart.  It does it already for 32 by 
32 bit divisions, but not for 64 by 32 divisions. Fortunately, with 
gcc-4 at least, constant propagation on long longs works well enough to 
do it by hand.  That's how I implemented do_div() for ARM years ago.  
See arch/arm/include/asm/div64.h from line 65.  The same could be 
implemented for x86 and others.


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/