Re: Accelerating Y2038 glibc fixes

[Alistair Francis <alistair23 at gmail dot com>]

On Fri, Jul 19, 2019 at 10:44 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 19/07/2019 00:06, Rich Felker wrote:
> > On Thu, Jul 18, 2019 at 05:31:51PM -0300, Adhemerval Zanella wrote:
> >>
> >>
> >> On 18/07/2019 16:13, Florian Weimer wrote:
> >>> * Adhemerval Zanella:
> >>>
> >>>> So what about to not add a user-selected way to set the time_t size
> >>>> (as off_t) and just enable time64_t support and sets is as default for
> >>>> build with a minimum kernel of v5.1 (if I recall correctly as being the
> >>>> one that added time64 support)?
> >>>
> >>> Does this mean that some developers see a glibc 2.31 with a 32-bit
> >>> time_t on i386, and others see a 64-bit time_t?
> >>>
> >>>> It will move all time32 support as compat symbols for the required ABI,
> >>>> without an option to select it through a build flag. Newer ports will
> >>>> just have the expected symbol names, no tinkering needed.
> >>>
> >>> But if we build glibc with pre-5.1 kernel headers, you will get the
> >>> legacy interface?
> >>
> >> My idea is to setup based on --enable-kernel and add a new EI_ABIVERSION
> >> when time64 is used.  So, depending on how glibc is built, developers
> >> will indeed see a different time_t.
> >>
> >> Legacy builds won't build any time64 support, even with newer kernels.
> >> Build set with --enable-kernel will automatically set time_t as time64
> >> and redirect the required interfaces to the new symbols ones (similar
> >> to LFS, but transparently as _FILE_OFFSET_BITS=64 as being set as default).
> >>
> >> Newer 32-bit ports won't require anything like this as expected.
> >>
> >> I still think that in long term this initial bump transition is better
> >> than to the complexity from mixed support.
> >
> > I see no reason for it to depend on the minimum kernel version glibc
> > is built for. You should be able to build glibc that runs on the
> > oldest still-supported kernels and that uses 64-bit time_t in the
> > application-facing ABI.
> >
> > If built with --enable-kernel new enough, the fallback code to use old
> > syscalls when the time64 ones fail with ENOSYS can be omitted. If not,
> > the time64 syscalls are tried first, and if they fail, the old
> > syscalls are used and the results converted.
> >
> > This is what musl has always planned to do regardless of whether we go
> > with a hard ABI break or symbol redirection. "Only works on
> > bleeding-edge kernels" is a sure way to make sure nobody uses the new
> > thing, resulting in continued production of legacy binaries that are
> > ticking timebombs far into the future, and all the exploding popcorn
> > when 2038 approaches...
>
> I am aiming for make the required changes less complex and allow the
> distributions to have a way to actually set or not whether to support
> time64, since you can still build glibc aiming for default minimum
> (3.2) while still providing a time64 enabled kernel.  I personally prefer
> to just make the switch based on release rather than a configure option.
>
> And I do agree with you that it is feasible to just make the switch
> on glibc 2.31 for all 32-bit architectures and move on. However
> we will need to take care of glibc some conventions, so instead of just
>
> --
> #if __LINUX_KERNEL_VERSION >= 0x050100
> # define __ASSUME_TIME64_SYSCALLS 1
> #endif
>
> int
> syscall_name (...)
> {
> #ifdef __ASSUME_TIME64_SYSCALLS
>   return INLINE_SYSCALL_CALL (syscall64, ...);
> #else
>   return INLINE_SYSCALL_CALL (syscall, ...);
> #endif
> }
> ---
>
> We will need to have something like:
>
> --
> #if __LINUX_KERNEL_VERSION >= 0x050100 >= 0x050100
> # define __ASSUME_TIME64_SYSCALLS 1
> #endif
>
> int
> syscall_name (args...)
> {
> #ifdef __ASSUME_TIME64_SYSCALLS
>   return INLINE_SYSCALL_CALL (syscall64, args...);
> #else
>   int ret;
> # ifdef __NR_syscall64
>   static int syscall_name_supported = 1;
>   if (atomic_read_relaxed (&syscall_name_supported) == 1)
>     {
>       ret = INLINE_SYSCALL_CALL (syscall64, args...);
>       if (ret == 0 || errno != ENOSYS)
>         return ret;
>
>       atomic_store_relaxed (&syscall_name_supported, 0)
>     }
> # endif /* __NR_syscall64  */
>
>   ret = INLINE_SYSCALL_CALL (syscall, args...);
>   if (ret == 0)
>     ret = convert_syscall_time_to_time64 (args, ...);
>   return ret;
> #endif
> }
> --

Great! This was my understanding as well (although not every patch in
the latest RV32 RFC does this, that is an oversight).

>
> For the syscall implementation. We will have some more complexity to handle
> vDSO, but it should be simplified with my refactor.

Also good news!

Alistair