[PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec

[PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec

[Lukasz Majewski]

This macro allows conversion between Y2038 safe struct __timespec64 and
struct timespec.
The struct __timespec64's tv_nsec field is checked if it is in the correct
range.
Moreover, the tv_sec is asserted if it fits into the time_t range.
When error is detected the errno is set accordingly and the function, which
uses this macro returns -1.

Tested with scripts/build-many-glibcs.py script.
---
 include/time.h | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/include/time.h b/include/time.h
index d93b16a781..c2b6c9b842 100644
--- a/include/time.h
+++ b/include/time.h
@@ -236,5 +236,28 @@ valid_timespec64_to_timeval (const struct __timespec64 ts64)
 
   return tv;
 }
+
+/* Check if a value lies with the valid nanoseconds range.  */
+#define IS_VALID_NANOSECONDS(ns) ((ns) >= 0 && (ns) <= 999999999)
+
+/* Check and convert a struct __timespec64 into a struct timespec.
+   This macro checks if the valid number of nanoseconds has been provided
+   by ts64 and if not the errno is set to EINVAL and -1 is returned.
+   Moreover, the number of seconds is check as well, if it is in the time_t
+   range. If not the errno is set to EOVERFLOW and -1 is returned.  */
+#define timespec64_to_timespec(ts64)                                           \
+  ({                                                                           \
+    if (! IS_VALID_NANOSECONDS (ts64.tv_nsec))                                 \
+      {                                                                        \
+        __set_errno (EINVAL);                                                  \
+        return -1;                                                             \
+      }                                                                        \
+    if (! in_time_t_range (ts64.tv_sec))                                       \
+      {                                                                        \
+        __set_errno (EOVERFLOW);                                               \
+        return -1;                                                             \
+      }                                                                        \
+    valid_timespec64_to_timespec (ts64); })
+
 #endif
 #endif
-- 
2.20.1

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

[Lukasz Majewski]

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

diff --git a/include/time.h b/include/time.h
index c2b6c9b842..cefc27ebb9 100644
--- a/include/time.h
+++ b/include/time.h
@@ -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.
diff --git a/sysdeps/unix/sysv/linux/clock_getres.c b/sysdeps/unix/sysv/linux/clock_getres.c
index 0b82759043..e5b4bf7cea 100644
--- a/sysdeps/unix/sysv/linux/clock_getres.c
+++ b/sysdeps/unix/sysv/linux/clock_getres.c
@@ -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;
-- 
2.20.1

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

[Joseph Myers]

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

Re: [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec

[Paul Eggert]

On 10/18/19 7:57 AM, Lukasz Majewski wrote:

> +/* Check if a value lies with the valid nanoseconds range.  */
> +#define IS_VALID_NANOSECONDS(ns) ((ns) >= 0 && (ns) <= 999999999)

This should be a static or inline function; there's no need for the 
excessive power of a macro here.

> +#define timespec64_to_timespec(ts64)                                           \
> +  ({                                                                           \
> +    if (! IS_VALID_NANOSECONDS (ts64.tv_nsec))                                 \
> +      {                                                                        \
> +        __set_errno (EINVAL);                                                  \
> +        return -1;                                                             \
> +      }                                                                        \
> +    if (! in_time_t_range (ts64.tv_sec))                                       \
> +      {                                                                        \
> +        __set_errno (EOVERFLOW);                                               \
> +        return -1;                                                             \
> +      }                                                                        \
> +    valid_timespec64_to_timespec (ts64); })

This macro is too confusing. Instead, if there's a need for this sort of 
thing, I suggest a static or inline function that returns true or false 
(setting errno); the caller can decide what to do if it returns false.

Re: [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 2520 bytes --]

Hi Paul,

> On 10/18/19 7:57 AM, Lukasz Majewski wrote:
> 
> > +/* Check if a value lies with the valid nanoseconds range.  */
> > +#define IS_VALID_NANOSECONDS(ns) ((ns) >= 0 && (ns) <= 999999999)  
> 
> This should be a static or inline function; there's no need for the 
> excessive power of a macro here.

Ok. I can add this as an inline static function.

> 
> > +#define timespec64_to_timespec(ts64)
> >             \
> > +  ({
> >             \
> > +    if (! IS_VALID_NANOSECONDS (ts64.tv_nsec))
> >             \
> > +      {
> >             \
> > +        __set_errno (EINVAL);
> >             \
> > +        return -1;
> >             \
> > +      }
> >             \
> > +    if (! in_time_t_range (ts64.tv_sec))
> >             \
> > +      {
> >             \
> > +        __set_errno (EOVERFLOW);
> >             \
> > +        return -1;
> >             \
> > +      }
> >             \
> > +    valid_timespec64_to_timespec (ts64); })  
> 
> This macro is too confusing. Instead, if there's a need for this sort
> of thing, I suggest a static or inline function that returns true or
> false (setting errno);

My first attempt on this conversion helper was based on static inline
function. Unfortunately, such approach has the issue with __set_errno(),
which is not accessible in include/time.h (as it is defined in
include/errno.h).

Moreover, in the glibc the pattern with defining such macros is widely
used - in e.g. math/math-narrow.h or in various sysdep.h headers.

Last but not least - as Joseph pointed out in the other mail - maybe it
would be just enough in this particular case to drop the
IS_VALID_NANOSECONDS() check as this shall be done in the kernel (and
if an error is detected the syscall would fail).
The in_time_t_range() check for clock_getres is also problematic - as
it would be required to have a _really_ bad clock with tv_sec to be
overflowed.

To sum up - for the clock_getres() conversion - I do opt for using
valid_timespec64_to_timespec() (as it is already available in
include/time.h) and drop this patch (but keeping the
IS_VALID_NANOSECONDS() check in the form of static inline).

> the caller can decide what to do if it returns
> false.




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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Lukasz Majewski]

[-- Attachment #1: Type: text/plain, Size: 3463 bytes --]

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

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]