* [PATCH 2/2] y2038: linux: Provide __clock_getres64 implementation
2019-10-18 14:57 [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec Lukasz Majewski
@ 2019-10-18 14:57 ` Lukasz Majewski
2019-10-18 15:38 ` Joseph Myers
2019-10-18 17:36 ` [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec Paul Eggert
1 sibling, 1 reply; 6+ messages in thread
From: Lukasz Majewski @ 2019-10-18 14:57 UTC (permalink / raw)
To: Joseph Myers, Paul Eggert
Cc: Alistair Francis, Arnd Bergmann, Alistair Francis, GNU C Library,
Adhemerval Zanella, Florian Weimer, Carlos O'Donell,
Stepan Golosunov, Florian Weimer, Zack Weinberg, 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec
@ 2019-10-18 14:57 Lukasz Majewski
2019-10-18 14:57 ` [PATCH 2/2] y2038: linux: Provide __clock_getres64 implementation Lukasz Majewski
2019-10-18 17:36 ` [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec Paul Eggert
0 siblings, 2 replies; 6+ messages in thread
From: Lukasz Majewski @ 2019-10-18 14:57 UTC (permalink / raw)
To: Joseph Myers, Paul Eggert
Cc: Alistair Francis, Arnd Bergmann, Alistair Francis, GNU C Library,
Adhemerval Zanella, Florian Weimer, Carlos O'Donell,
Stepan Golosunov, Florian Weimer, Zack Weinberg, 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] y2038: linux: Provide __clock_getres64 implementation
2019-10-18 14:57 ` [PATCH 2/2] y2038: linux: Provide __clock_getres64 implementation Lukasz Majewski
@ 2019-10-18 15:38 ` Joseph Myers
2019-10-19 6:16 ` Lukasz Majewski
0 siblings, 1 reply; 6+ messages in thread
From: Joseph Myers @ 2019-10-18 15:38 UTC (permalink / raw)
To: Lukasz Majewski
Cc: Paul Eggert, Alistair Francis, Arnd Bergmann, Alistair Francis,
GNU C Library, Adhemerval Zanella, Florian Weimer,
Carlos O'Donell, Stepan Golosunov, Florian Weimer,
Zack Weinberg
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
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec
2019-10-18 14:57 [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec Lukasz Majewski
2019-10-18 14:57 ` [PATCH 2/2] y2038: linux: Provide __clock_getres64 implementation Lukasz Majewski
@ 2019-10-18 17:36 ` Paul Eggert
2019-10-18 20:44 ` Lukasz Majewski
1 sibling, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2019-10-18 17:36 UTC (permalink / raw)
To: Lukasz Majewski; +Cc: GNU C Library
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec
2019-10-18 17:36 ` [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec Paul Eggert
@ 2019-10-18 20:44 ` Lukasz Majewski
0 siblings, 0 replies; 6+ messages in thread
From: Lukasz Majewski @ 2019-10-18 20:44 UTC (permalink / raw)
To: Paul Eggert; +Cc: GNU C Library
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [PATCH 2/2] y2038: linux: Provide __clock_getres64 implementation
2019-10-18 15:38 ` Joseph Myers
@ 2019-10-19 6:16 ` Lukasz Majewski
0 siblings, 0 replies; 6+ messages in thread
From: Lukasz Majewski @ 2019-10-19 6:16 UTC (permalink / raw)
To: Joseph Myers
Cc: Paul Eggert, Alistair Francis, Arnd Bergmann, Alistair Francis,
GNU C Library, Adhemerval Zanella, Florian Weimer,
Carlos O'Donell, Stepan Golosunov, Florian Weimer,
Zack Weinberg
[-- 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 --]
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2019-10-19 6:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-18 14:57 [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec Lukasz Majewski
2019-10-18 14:57 ` [PATCH 2/2] y2038: linux: Provide __clock_getres64 implementation Lukasz Majewski
2019-10-18 15:38 ` Joseph Myers
2019-10-19 6:16 ` Lukasz Majewski
2019-10-18 17:36 ` [PATCH 1/2] y2038: Helper macro to convert struct __timespec64 to struct timespec Paul Eggert
2019-10-18 20:44 ` Lukasz Majewski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).