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

[Joseph Myers <joseph at codesourcery dot com>]

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.

-- 
Joseph S. Myers
joseph@codesourcery.com