Re: Accelerating Y2038 glibc fixes

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

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
}
--

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