Re: Accelerating Y2038 glibc fixes

[Zack Weinberg <zackw at panix dot com>]

On Fri, Jul 26, 2019 at 6:39 AM Lukasz Majewski <lukma@denx.de> wrote:
...
> > > See for example [1] - there are just 7 lines of "code".  But Joseph
> > > does not accept our patches.  The arguments he gives are not on a
> > > technical level;
...
> Our goal is to add a solid foundation for the Y2038 work, so we would
> know the direction where we are heading.
...
> If you think that it would be better and most of all faster if you
> rewrite the description, then I don't mind.
>
> It would be great if you could do it sooner than latter as this slows
> down our development.
...
> The most recent version of this patch set (v8):
> https://patchwork.ozlabs.org/patch/1117100/

I haven’t been following the details of these patches super carefully,
and I’m not sure I understand what _Joseph’s_ concerns with your
writing is.  However, I’m a native English speaker, I’ve read over the
text in the patch at <https://patchwork.ozlabs.org/patch/1117100/>, I
do think I understand the issues at a high level, and I do think the
meaning of __ASSUME_TIME64_SYSCALLS could be explained more clearly.
I’m prepared to work with you to come up with better wording but I
need to ask you a bunch of questions.  Could you please reply to each
of the queries marked Qn below?

As I understand it, we have five distinct cases to consider:

1. All future LP64 ABIs and all but one existing LP64 ABI, identified
   by __WORDSIZE == 64: time_t is already a 64-bit integer type and
   all of the relevant system calls already accept it in that form.
   glibc’s implementation of, for instance, clock_gettime may continue
   to invoke the system call numbered __NR_clock_gettime.

2. The exception to (1) is Alpha.  That is an exclusively LP64
   architecture, but in glibc 2.0 it used 32-bit time_t, and we still
   have compatibility code for that case.  The compatibility symbols
   invoke a set of compatibility syscalls with ‘osf’ in their names:
   for instance, gettimeofday@GLIBC_2.0 invokes __NR_osf_gettimeofday.
   Not all of the time-related functions in glibc have compatibility
   symbols, only those that existed in version 2.0.

   Your patches do not touch this compatibility code at all, as far as
   I can see.  Alpha being out of production, and binaries compiled
   against glibc 2.0 being rare anyway, it would only make sense to
   involve this code in your patches if it reduced the overall volume
   of compatibility code somehow, but regardless we need to make sure
   it doesn't break.

3. x32 (recently new 32-bit ABI for x86): like case 1, time_t is
   already 64-bit and we use unsuffixed system calls.  The text says
   this case is identified by __WORDSIZE == 32 && __TIMESIZE == 64,
   but the code actually checks __SYSCALL_WORDSIZE.

   Q1: Which condition correctly identifies this case, __TIMESIZE == 64 or
   __SYSCALL_WORDSIZE == 64?

   Q2: Could we perhaps ensure that __TIMESIZE and/or __SYSCALL_WORDSIZE
   is defined to 64 whenever __WORDSIZE == 64? Then we could collapse
   this into case 1.

4. Brand-new (added in kernel 5.1 or later) 32-bit ABIs: time_t will
   always be 64-bit, _but_ glibc’s implementation of time-related APIs
   may need to invoke system calls with suffixed names: clock_gettime
   invoking __NR_clock_gettime64, for instance.  Also, the kernel will
   not provide all of the time-related system calls that have
   historically existed; glibc must, for instance, implement
   gettimeofday in terms of clock_gettime.

   Q3: What macros are defined for this case?

   Q4: Does glibc need to call system calls with suffixed names in
   this case?

   Q4a: If the answer to Q4 is ‘yes’, why is that, and can we change
   the kernel so that it’s the same as x32 and the LP64 architectures?
   (Either by removing the suffixes, or by _adding_ suffixed aliases
   to asm/unistd.h for x32 and LP64 architectures.)

5. Historical 32-bit ABIs, where the existing set of system calls
   takes 32-bit time_t, and Linux 5.1 added a matching set that takes
   64-bit time_t.  For compatibility with old programs that make
   direct system calls, the kernel will not rename the __NR_ constants
   for the old (32-bit) system calls; instead new constants with ‘64’
   or ‘time64’ suffixes will be added.  As in case 4, the new set of
   system calls does not cover all of the historic time-related system
   calls.

   In this case, and only this case, glibc’s code needs to account for
   the possibility that the new __NR_ constants are not defined
   (because glibc is being compiled against kernel headers from a
   version older than 5.1), or that the new system calls are not
   available at runtime (glibc was compiled against new kernel headers
   but is running with an old kernel).

   The #if is complicated enough that I’m not sure, but I _think_ your
   code only defines __ASSUME_TIME64_SYSCALLS when the new constants
   are _guaranteed_ to be defined.

   Q5: Is it correct that __ASSUME_TIME64_SYSCALLS is only defined
   when the new constants are guaranteed to be defined?

   Q6: All of the other __ASSUME_ constants mean both that we assume
   the kernel headers are new enough to provide all the necessary
   declarations, and that we assume the feature is available at
   runtime: no fallback code will be included in the library.  Is this
   also the intended meaning of __ASSUME_TIME64_SYSCALLS?

zw