public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: "Dr. Todor Dimitrov" <dimitrov@technology.de>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: libc-help@sourceware.org
Subject: Re: Glibc 2.31 - time64 with 64-bit kernel and 32-bit userland
Date: Mon, 18 Jan 2021 21:10:08 +0100	[thread overview]
Message-ID: <50B1F5BE-B5F2-4CDB-AF4D-9CE2181B118C@technology.de> (raw)
In-Reply-To: <ee5056b2-a4b3-48a4-c3ba-a914a0df2248@linaro.org>

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

OK, thank you for the detailed explanation.

> On 18. Jan 2021, at 20:31, Adhemerval Zanella <adhemerval.zanella@linaro.org> wrote:
> 
> 
> 
> 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.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 3895 bytes --]

  reply	other threads:[~2021-01-18 20:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-18 17:43 Dr. Todor Dimitrov
2021-01-18 17:51 ` Florian Weimer
2021-01-18 17:57   ` Dr. Todor Dimitrov
2021-01-18 19:31 ` Adhemerval Zanella
2021-01-18 20:10   ` Dr. Todor Dimitrov [this message]
2021-01-18 20:14   ` Florian Weimer
2021-01-18 20:31     ` Adhemerval Zanella
2021-01-18 20:35       ` Florian Weimer
2021-01-18 21:22         ` Adhemerval Zanella
2021-01-19 11:23           ` Adhemerval Zanella

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50B1F5BE-B5F2-4CDB-AF4D-9CE2181B118C@technology.de \
    --to=dimitrov@technology.de \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).