Re: Glibc 2.31 - time64 with 64-bit kernel and 32-bit userland

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 18/01/2021 14:43, Dr. Todor Dimitrov wrote:
> Hello,
> 
> we’ve recently updated an `aarch64` system to Glibc 2.31 and we’ve started seeing a lot of failing 403 and 407 syscalls. The kernel version is 4.1.52 and the userland is 32-bit. Looking at the implementation of `__clock_gettime64`, it seems that we are hitting the following problem:
> 
>   /* Old 32-bit ABI with possible 64-bit time_t support.  */
> # ifdef __NR_clock_gettime64
>   /* Avoid issue a __NR_clock_gettime64 syscall on kernels that do not
>      support 64-bit time_t.  */
>   static int time64_support = 1;
>   if (atomic_load_relaxed (&time64_support) != 0)
>     {
> #  ifdef HAVE_CLOCK_GETTIME64_VSYSCALL
>       r = INLINE_VSYSCALL (clock_gettime64, 2, clock_id, tp);
> #  else
>       r = INLINE_SYSCALL_CALL (clock_gettime64, clock_id, tp);
> #  endif
>       if (r == 0 || errno != ENOSYS)
> 	return r;
> 
>       atomic_store_relaxed (&time64_support, 0);
>     }
> # endif
> 
> `__NR_clock_gettime64` is defined for the 32-bit `arm` architecture but not for `aarch64`. Is this a known issue? What would be the best way to overcome it?

This is the expected behavior, running this small example:

--
#include <time.h>

int main (int argc, char *argv[])
{
  clock_gettime (CLOCK_REALTIME, &((struct timespec) {}));
  clock_gettime (CLOCK_BOOTTIME, &((struct timespec) {}));
  return 0;
}
--

On a aarch64 kernel without 64-bit compat time_t support (4.12.13),
this is the generated syscalls:

--
clock_gettime64(CLOCK_REALTIME, 0xfffebb58) = -1 ENOSYS (Function not implemented)
clock_gettime(CLOCK_REALTIME, {tv_sec=1610997887, tv_nsec=516302599}) = 0
clock_gettime(CLOCK_BOOTTIME, {tv_sec=2750059, tv_nsec=271773400}) = 0
--

The catch here the 64-bit kernel when running 32-bit userland will
use compat entrypoints to provide the expected kernel ABI. For kernel 
older than v5.1, it means that even if kernel is 64-bit and support 
64-bit time_t, the 32-bit syscall entrypoints won't have 64-bit time_t
support.

The glibc Linux clock_gettime thus probes by first issuing the new
syscall with provides 64-bit time_t support and then falling back
to older in case kernel does not support it.

For clock_gettime and a some other handfull implementations, it would
incur in only one ENOSYS.  However there are a bunch of implementations
that do not have this optimization.