[v3,4/5] y2038: linux: Provide __clock_settime64 implementation

  This patch provides new __clock_settime64 explicit 64 bit function for
setting the time. Moreover, a 32 bit version - __clock_settime has been
refactored to internally use __clock_settime64.

The __clock_settime is now supposed to be used on systems still supporting
32 bit time - hence the necessary checks and conversion to 64 bit type.
After this change it is intrinsically Y2038 safe.

The new 64 bit syscall (clock_settime64) available from Linux
5.1+ has been used when applicable on 32 bit systems.

The __ASSUME_TIME64_SYSCALLS flag indicates if the Linux kernel provides
64 bit version of clock_settime (i.e. clock_settime64). If this syscall is
not provided by the kernel - the 32 bit version of it is executed instead.

When working on 32 bit systems without Y2038 time support the clock_settime
returns error when one wants to set time with wrong (overflowed) tv_sec
value. Moreover, the correctness of tv_nsec is checked.

In this patch the internal padding (tv_pad) of struct __timespec64 is
left untouched (on 32 bit systems) as Linux kernel ignores upper 32 bits
of tv_nsec.

The execution path on 64 bit systems has not been changed or affected in
any way.

Tests:
- The code has been tested with x86_64/x86 (native compilation):
make PARALLELMFLAGS="-j8" && make xcheck PARALLELMFLAGS="-j8"

- 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
on kernels with and without 64 bit time support.

No regressions were observed.

* include/time.h (__clock_settime64):
  Add __clock_settime alias according to __TIMESIZE define
* sysdeps/unix/sysv/linux/clock_settime.c (__clock_settime):
  Refactor this function to be used only on 32 bit machines as a wrapper
  on __clock_settime64.
* sysdeps/unix/sysv/linux/clock_settime.c (__clock_settime64): Add
* sysdeps/unix/sysv/linux/clock_settime.c (__clock_settime64):
  Use clock_settime64 kernel syscall (available from 5.1-rc1+ Linux) by
  32 bit Y2038 safe systems

---
Changes for v3:
- Rename __ASSUME_64BIT_TIME to __ASSUME_TIME64_SYSCALLS
- Refactor in-code comment (add information regarding Linux kernel ignorance
  of padding
- Do not use __TIMESIZE to select main execution path (for Y2038 systems
  __TIMESIZE would be changed from 32 to 64 bits at some point to indicate
  full Y2038 support

Changes for v2:
- Add support for __ASSUME_64BIT_TIME flag when Linux kernel provides syscalls
  supporting 64 bit time on 32 bit systems
- Provide fallback to 32 bit version of clock_settime when clock_settime64
  is not available
- Do not copy *tp to timespec - this seems like an overkill as in clock_settime()
  the 32 bit struct timespec is copied to internal 64 bit struct __timespec64
---
 include/time.h                          |  8 +++++
 sysdeps/unix/sysv/linux/clock_settime.c | 53 +++++++++++++++++++++++++++++++--
 2 files changed, 58 insertions(+), 3 deletions(-)
  

On Tue, 7 May 2019, Lukasz Majewski wrote:

> +#ifdef __ASSUME_TIME64_SYSCALLS
> +# ifdef __NR_clock_settime64
> +  /* For Y2038 safe systems with __WORDSIZE==32 and __TIMESIZE==64
> +     (x86, arm) the glibc exported struct timespec has 64 bit tv_sec,
> +     32 bit tv_nsec (to be still POSIX compliant -> long tv_nsec )
> +     and 32 bits of unnamed padding.
> +
> +     It may happen that due to dynamic allocation the tv_pad, which
> +     corresponds to upper 32 bits of kernel's 64 bit tv_nsec accepted
> +     by syscalls, may not be zero.
> +
> +     However, the Linux kernel is ignoring those 32 bits (to be more
> +     precise - as of 5.1 - it casts 64 bit tv_nsec to internal's 32 bit
> +     representation) and hence the padding clearing is not needed.  */
> +  int ret = INLINE_SYSCALL_CALL (clock_settime64, clock_id, tp);
> +  if (ret == 0 || errno != ENOSYS)
> +    return ret;
> +# endif

This logic is wrong.  If __ASSUME_TIME64_SYSCALLS is defined, then:

(a) There should be no special ENOSYS check, as the syscall is guaranteed 
to be present; just return its return value.

(b) There is no need for a check of whether __NR_clock_settime64 is 
defined, because the kernel headers are always at least as new as the 
minimum runtime kernel version; a build failure if __NR_clock_settime64 is 
somehow not defined, despite __ASSUME_TIME64_SYSCALLS being defined, is 
entirely appropriate.

Tests of __NR_clock_settime64 being defined are entirely appropriate 
if __ASSUME_TIME64_SYSCALLS is *not* defined; likewise runtime tests for 
an ENOSYS return to determine whether in fact the syscall existed or 
whether a fallback to the older syscalls is needed.