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: <alpine.DEB.2.11.1504211701140.13914@nanos>
Date:	Tue, 21 Apr 2015 17:13:32 +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:
> On Tuesday 21 April 2015 16:14:26 Thomas Gleixner wrote:
> > > Note the use of a separate __kernel_itimerspec64 for the user interface
> > > here, which I think will be needed to hide the differences between the
> > > normal itimerspec on 64-bit machines, and the new itimerspec on 32-bit
> > > platforms that will be defined differently (using 'long long').
> > 
> > Confused.
> > 
> > timespec64 / itimerspec64 should be the same independent of 64bit and
> > 32bit. So why do we need another variant ?
> 
> There are multiple reasons:
> 
> * On 64-bit systems, timespec64 would always be defined in the same way
>   as struct timespec { __kernel_time_t tv_sec; long tv_nsec; }, with
>   __kernel_time_t being 'long'. On 32-bit, we probably need to make both
>   members 'long long' for the user space side, in order to share the
>   syscall implementation with the kernel side, but we may also want to
>   keep the internal timespec64 using a 'long' for tv_nsec, as we do
>   today. This means that both the binary layout (padding or no padding)
>   and the basic types (long or long long) are different between 32-bit
>   and 64-bit, and between kernel and user space

So you want to avoid a compat syscall for 32bit applications on a
64bit kernel, right?

That burdens 32bit with the extra 'long long' in user space. Not sure
whether user space folks will be happy about it.

> * We should not put 'struct timespec64' into the user space namespace,
>   as applications might already use that identifier. This is similar
>   to the __u32/u32 or __kernel_time_t/time_t tuple of types for interface
>   and in-kernel uses. This is particularly important when embedding a
>   timespec in another data structure.

Fair enough.

> * My plan is to use a temporary hack where I actually define
>   __kernel_timespec64 to look like the 32-bit version of timespec,
>   as an intermediate step when converting all 32-bit architectures over
>   to use the compat_*() syscalls in place of the existing ones, so
>   I can change over the normal syscalls to use __kernel_timespec64
>   without having to change all architectures at once, or having to
>   modify each syscall multiple times.

Makes sense.

Thanks,

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