[2/2] y2038: linux: Provide __clock_getres64 implementation
Commit Message
This patch provides new __clock_getres64 explicit 64 bit function for
getting the resolution (precision) of specified clock ID. Moreover, a
32 bit version - __clock_getres has been refactored to internally use
__clock_getres64.
The __clock_getres is now supposed to be used on systems still supporting
32 bit time (__TIMESIZE != 64) - hence the necessary conversion from 64 bit
struct __timespec64 to struct timespec.
The new clock_getres_time64 syscall available from Linux 5.1+ has been used,
when applicable.
On systems which are not supporting clock_getres_time64 (as their
clock_getres supports 64 bit time ABI) the vDSO syscall is attempted.
On the contrary the non-vDSO syscall is used for clock_getres_time64 as
up till now the kernel is not providing such interface.
When working on systems still supporting 32 bit time (__TIMESIZE != 64)
without Y2038 time support the clock_getres returns error when received
tv_sec excess time_t range (i.e. overflow 32 bit type).
Moreover, the correctness of tv_nsec is checked.
Build tests:
- The code has been tested on x86_64/x86 (native compilation):
make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8"
- The glibc has been build tested (make PARALLELMFLAGS="-j8") for
x86 (i386), x86_64-x32, and armv7
Run-time tests:
- Run specific tests on ARM/x86 32bit systems (qemu):
https://github.com/lmajewski/meta-y2038 and run tests:
https://github.com/lmajewski/y2038-tests/commits/master
- Use of cross-test-ssh.sh for ARM (armv7):
make PARALLELMFLAGS="-j8" test-wrapper='./cross-test-ssh.sh root@192.168.7.2' xcheck
Linux kernel, headers and minimal kernel version for glibc build test
matrix:
- Linux v5.1 (with clock_getres_time64) and glibc build with v5.1 as
minimal kernel version (--enable-kernel="5.1.0")
The __ASSUME_TIME64_SYSCALLS flag defined.
- Linux v5.1 and default minimal kernel version
The __ASSUME_TIME64_SYSCALLS not defined, but kernel supports
clock_getres_time64 syscall.
- Linux v4.19 (no clock_getres_time64 support) with default minimal kernel
version for contemporary glibc
This kernel doesn't support clock_getres_time64 syscall, so the fallback
to clock_getres is tested.
The above tests were performed with Y2038 redirection applied as well as
without (so the __TIMESIZE != 64 execution path is checked as well).
No regressions were observed.
---
include/time.h | 8 ++++++
sysdeps/unix/sysv/linux/clock_getres.c | 38 ++++++++++++++++++++++++--
2 files changed, 43 insertions(+), 3 deletions(-)
Comments
On Fri, 18 Oct 2019, Lukasz Majewski wrote:
> When working on systems still supporting 32 bit time (__TIMESIZE != 64)
> without Y2038 time support the clock_getres returns error when received
> tv_sec excess time_t range (i.e. overflow 32 bit type).
> Moreover, the correctness of tv_nsec is checked.
It's definitely not necessary to check if the kernel returned a valid
tv_nsec value; that can be assumed if the syscall succeeded at all. I'm
doubtful about the check for overflow in this case (a clock whose
resolution exceeds 68 years does not seem a very useful clock), but that
check is at least theoretically relevant.
A stronger justification for the helper macro in patch 1/2 would be if you
have a patch that uses it to check a timespec64 value coming from the
*user* rather than from the kernel (that is, coming from the caller to one
of the __*64 functions that will end up being directly called by code
built with _TIME_BITS=64).
If a function needs to check the nanoseconds value (rather than deferring
to a kernel check of that value), I'd expect it to need to so such a check
regardless of whether it needs to convert 64-bit time to 32-bit time. For
example, that's what __clock_settime64 does - checks nanoseconds before
calling into the kernel at all. So it's not clear to me that there is
actually a use case for a macro that combines a check of the nanoseconds
value with a conversion from 64-bit to 32-bit time.
There *is* definitely a use for a macro such as the IS_VALID_NANOSECONDS
macro in the first patch. Perhaps it would make sense to factor out and
send a patch that just adds that macro and makes existing code with such
checks use it. (See io/ppoll.c, nptl/sem_clockwait.c,
nptl/sem_timedwait.c, sysdeps/htl/pt-cond-timedwait.c,
sysdeps/htl/pt-mutex-timedlock.c, sysdeps/htl/pt-rwlock-timedrdlock.c,
sysdeps/htl/pt-rwlock-timedwrlock.c, sysdeps/htl/sem-timedwait.c,
sysdeps/mach/nanosleep.c, sysdeps/pthread/timer_settime.c,
sysdeps/sparc/sparc32/lowlevellock.c, sysdeps/unix/clock_nanosleep.c,
sysdeps/unix/clock_settime.c, sysdeps/unix/sysv/linux/clock_settime.c,
time/clock_nanosleep.c for examples of files with checks that look like
they could use such a macro - not necessarily an exhaustive list. Note
that a few of those files use __builtin_expect, thus suggesting that the
macro definition could use __glibc_likely to reflect that nanoseconds
values almost certainly are valid in real use.)
Hi Joseph,
> On Fri, 18 Oct 2019, Lukasz Majewski wrote:
>
> > When working on systems still supporting 32 bit time (__TIMESIZE !=
> > 64) without Y2038 time support the clock_getres returns error when
> > received tv_sec excess time_t range (i.e. overflow 32 bit type).
> > Moreover, the correctness of tv_nsec is checked.
>
> It's definitely not necessary to check if the kernel returned a valid
> tv_nsec value; that can be assumed if the syscall succeeded at all.
Ok.
> I'm doubtful about the check for overflow in this case (a clock whose
> resolution exceeds 68 years does not seem a very useful clock), but
> that check is at least theoretically relevant.
We can skip those two checks altogether (for clock_getres) and instead
use valid_timespec64_to_timespec() conversion helper function.
(then we would rely on kernel providing valid range or return syscall
with error).
>
> A stronger justification for the helper macro in patch 1/2 would be
> if you have a patch that uses it to check a timespec64 value coming
> from the *user* rather than from the kernel (that is, coming from the
> caller to one of the __*64 functions that will end up being directly
> called by code built with _TIME_BITS=64).
Yes, I do agree. One most apparent example is the clock_nanosleep
conversion, which would need such check on passed *request value (const
struct __timespec64 *request).
>
> If a function needs to check the nanoseconds value (rather than
> deferring to a kernel check of that value), I'd expect it to need to
> so such a check regardless of whether it needs to convert 64-bit time
> to 32-bit time. For example, that's what __clock_settime64 does -
> checks nanoseconds before calling into the kernel at all. So it's
> not clear to me that there is actually a use case for a macro that
> combines a check of the nanoseconds value with a conversion from
> 64-bit to 32-bit time.
Ok.
>
> There *is* definitely a use for a macro such as the
> IS_VALID_NANOSECONDS macro in the first patch. Perhaps it would make
> sense to factor out and send a patch that just adds that macro and
> makes existing code with such checks use it. (See io/ppoll.c,
> nptl/sem_clockwait.c, nptl/sem_timedwait.c,
> sysdeps/htl/pt-cond-timedwait.c, sysdeps/htl/pt-mutex-timedlock.c,
> sysdeps/htl/pt-rwlock-timedrdlock.c,
> sysdeps/htl/pt-rwlock-timedwrlock.c, sysdeps/htl/sem-timedwait.c,
> sysdeps/mach/nanosleep.c, sysdeps/pthread/timer_settime.c,
> sysdeps/sparc/sparc32/lowlevellock.c, sysdeps/unix/clock_nanosleep.c,
> sysdeps/unix/clock_settime.c,
> sysdeps/unix/sysv/linux/clock_settime.c, time/clock_nanosleep.c for
> examples of files with checks that look like they could use such a
> macro - not necessarily an exhaustive list. Note that a few of those
> files use __builtin_expect, thus suggesting that the macro definition
> could use __glibc_likely to reflect that nanoseconds values almost
> certainly are valid in real use.)
>
If we rely on kernel, then the IS_VALID_NANOSECONDS is not required for
clock_getres(). However, it would be beneficial to have it as static
inline function to be used in glibc.
Best regards,
Lukasz Majewski
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
@@ -133,6 +133,14 @@ extern int __clock_settime64 (clockid_t clock_id,
libc_hidden_proto (__clock_settime64)
#endif
+#if __TIMESIZE == 64
+# define __clock_getres64 __clock_getres
+#else
+extern int __clock_getres64 (clockid_t clock_id,
+ struct __timespec64 *tp);
+libc_hidden_proto (__clock_getres64);
+#endif
+
/* Compute the `struct tm' representation of T,
offset OFFSET seconds east of UTC,
and store year, yday, mon, mday, wday, hour, min, sec into *TP.
@@ -19,21 +19,53 @@
#include <sysdep.h>
#include <errno.h>
#include <time.h>
-#include "kernel-posix-cpu-timers.h"
#ifdef HAVE_CLOCK_GETRES_VSYSCALL
# define HAVE_VSYSCALL
#endif
#include <sysdep-vdso.h>
-
#include <shlib-compat.h>
+#include <kernel-features.h>
/* Get resolution of clock. */
int
-__clock_getres (clockid_t clock_id, struct timespec *res)
+__clock_getres64 (clockid_t clock_id, struct __timespec64 *res)
{
+#ifdef __ASSUME_TIME64_SYSCALLS
+# ifndef __NR_clock_getres_time64
return INLINE_VSYSCALL (clock_getres, 2, clock_id, res);
+# else
+ return INLINE_SYSCALL (clock_getres_time64, 2, clock_id, res);
+# endif
+#else
+# ifdef __NR_clock_getres_time64
+ int ret = INLINE_SYSCALL (clock_getres_time64, 2, clock_id, res);
+ if (ret == 0 || errno != ENOSYS)
+ return ret;
+# endif
+ struct timespec ts32;
+ int retval = INLINE_VSYSCALL (clock_getres, 2, clock_id, &ts32);
+ if (! retval && res)
+ *res = valid_timespec_to_timespec64 (ts32);
+
+ return retval;
+#endif
+}
+
+#if __TIMESIZE != 64
+int
+__clock_getres (clockid_t clock_id, struct timespec *res)
+{
+ struct __timespec64 ts64;
+ int retval;
+
+ retval = __clock_getres64 (clock_id, &ts64);
+ if (! retval && res)
+ *res = timespec64_to_timespec (ts64);
+
+ return retval;
}
+#endif
versioned_symbol (libc, __clock_getres, clock_getres, GLIBC_2_17);
/* clock_getres moved to libc in version 2.17;