[2/2] y2038: linux: Provide __clock_getres64 implementation

  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(-)
  

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