1
0
mirror of https://sourceware.org/git/glibc.git synced 2025-11-06 19:29:35 +03:00
Files
glibc/sysdeps/unix/sysv/linux/mq_timedreceive.c
Lukasz Majewski 0b65a8fbaf y2038: linux: Provide __mq_timedreceive_time64 implementation
This patch provides new __mq_timedreceive_time64 explicit 64 bit function for
receiving messages with absolute timeout.
Moreover, a 32 bit version - __mq_timedreceive has been refactored to
internally use __mq_timedreceive_time64.

The __mq_timedreceive is now supposed to be used on systems still supporting 32
bit time (__TIMESIZE != 64) - hence the necessary conversion to 64 bit struct
__timespec64 from struct timespec.

The new mq_timedsend_time64 syscall available from Linux 5.1+ has been used,
when applicable.

As this wrapper function is also used internally in the glibc, to e.g. provide
mq_receive implementation, an explicit check for abs_timeout being NULL has been
added due to conversions between struct timespec and struct __timespec64.
Before this change the Linux kernel handled this NULL pointer.

Build tests:
- ./src/scripts/build-many-glibcs.py glibcs

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

Linux kernel, headers and minimal kernel version for glibc build test matrix:
- Linux v5.1 (with mq_timedreceive_time64) and glibc built 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
  mq_timedreceive_time64 syscall.

- Linux v4.19 (no mq_timedreceive_time64 support) with default minimal kernel
  version for contemporary glibc (3.2.0)
  This kernel doesn't support mq_timedreceive_time64 syscall, so the fallback to
  mq_timedreceive is tested.

Above tests were performed with Y2038 redirection applied as well as without
(so the __TIMESIZE != 64 execution path is checked as well).

Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
2020-04-06 23:05:11 +02:00

2.7 KiB