netdev - 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: <063D6719AE5E284EB5DD2968C1650D6D1CB23A45@AcuExch.aculab.com>
Date:	Wed, 22 Apr 2015 10:44:50 +0000
From:	David Laight <David.Laight@...LAB.COM>
To:	'Thomas Gleixner' <tglx@...utronix.de>,
	Arnd Bergmann <arnd@...db.de>
CC:	"y2038@...ts.linaro.org" <y2038@...ts.linaro.org>,
	Baolin Wang <baolin.wang@...aro.org>,
	"pang.xunlei@...aro.org" <pang.xunlei@...aro.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Heiko Carstens <heiko.carstens@...ibm.com>,
	Paul Mackerras <paulus@...ba.org>,
	"cl@...ux.com" <cl@...ux.com>,
	"heenasirwani@...il.com" <heenasirwani@...il.com>,
	"linux-arch@...r.kernel.org" <linux-arch@...r.kernel.org>,
	"linux-s390@...r.kernel.org" <linux-s390@...r.kernel.org>,
	"mpe@...erman.id.au" <mpe@...erman.id.au>,
	"rafael.j.wysocki@...el.com" <rafael.j.wysocki@...el.com>,
	"ahh@...gle.com" <ahh@...gle.com>,
	"Frederic Weisbecker" <fweisbec@...il.com>,
	"pjt@...gle.com" <pjt@...gle.com>,
	"riel@...hat.com" <riel@...hat.com>,
	"richardcochran@...il.com" <richardcochran@...il.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	John Stultz <john.stultz@...aro.org>,
	"rth@...ddle.net" <rth@...ddle.net>,
	"gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	Tejun Heo <tj@...nel.org>,
	"linux390@...ibm.com" <linux390@...ibm.com>,
	"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
	Ingo Molnar <mingo@...nel.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>
Subject: RE: [Y2038] [PATCH 04/11] posix timers:Introduce the 64bit methods
 with timespec64 type for k_clock structure

From: Thomas Gleixner
> Sent: 22 April 2015 09:45
> On Tue, 21 Apr 2015, Thomas Gleixner wrote:
> > 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.
> 
> Second thoughts after some sleep.
> 
> So the outcome of this is going to be that user space libraries will
> not expose the syscall variant of
> 
>     syscall_timespec64 {
>            s64 tv_sec;
> 	   s64 tv_nsec;
>     };
> 
> to applications. The libs will translate them to spec conforming
> 
>    timespec {
>            time_t tv_sec;
> 	   long   tv_nsec;
>    };
> 
> anyway. That means we have two translation steps on 32bit systems:
> 
>   1) user space timespec -> syscall timespec64
> 
>   2) syscall timespec64 -> scalar nsec s64 (ktime_t)
> 
> and the other way round. The kernel internal representation is simply
> s64 (nsec) based all over the place.

Do you need the double-translation?
If all the kernel uses a 64bit nsec value the in-kernel syscall stub
can convert the user-supplied values appropriately before calling
the standard function.
Not that a syscall that takes a linear nsec value isn't useful.

FWIW I can't remember what NetBSD did when they extended time_t to 64bits.

	David

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html