linux-kernel - Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods with timespec64 type for k

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.DEB.2.11.1504212204130.13914@nanos>
Date:	Tue, 21 Apr 2015 22:13:42 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Arnd Bergmann <arnd@...db.de>
cc:	y2038@...ts.linaro.org, Baolin Wang <baolin.wang@...aro.org>,
	pang.xunlei@...aro.org, peterz@...radead.org,
	benh@...nel.crashing.org, heiko.carstens@...ibm.com,
	paulus@...ba.org, cl@...ux.com, heenasirwani@...il.com,
	linux-arch@...r.kernel.org, linux-s390@...r.kernel.org,
	mpe@...erman.id.au, rafael.j.wysocki@...el.com, ahh@...gle.com,
	fweisbec@...il.com, pjt@...gle.com, riel@...hat.com,
	richardcochran@...il.com, schwidefsky@...ibm.com,
	john.stultz@...aro.org, rth@...ddle.net,
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org,
	netdev@...r.kernel.org, tj@...nel.org, linux390@...ibm.com,
	linuxppc-dev@...ts.ozlabs.org
Subject: Re: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods
 with timespec64 type for k_clock structure

On Tue, 21 Apr 2015, Arnd Bergmann wrote:
> I know there are concerns about this, in particular because C11 and
> POSIX both require tv_nsec to be 'long', unlike timeval->tv_usec,
> which is a 'suseconds_t' and can be defined as 'long long'.
>
> a)
> 
> struct timespec {
> 	time_t tv_sec;
> 	long long tv_nsec; /* or typedef long long snseconds_t */
> };
> 
> This is not directly compatible with C11 or POSIX.1-2008, but it
> matches what we do inside of 64-bit kernels, so probably has the
> highest chance of working correctly in practice

After reading Linus rant in the x32 thread again (thanks for the
reminder), and looking at b/c/d - which rate between ugly and butt
ugly - I think we should go for a) and screw POSIX and C11 as those
committee dinosaurs seem to completely ignore the 2038 problem on
32bit machines. At least I have not found any hint that these folks
care at all. So why should we comply to something which is completely
useless?

That also makes the question about the upper 32bits check moot, so
it's the simplest and clearest of the possible solutions.

Thanks,

	tglx


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