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

[Joseph Myers <joseph at codesourcery dot com>]

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

-- 
Joseph S. Myers
joseph@codesourcery.com