Re: [PATCH 00/18] More y2038 fixes

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

On 17/06/2021 11:20, Lukasz Majewski wrote:
> Hi Adhemerval,
> 
>> Hi Carlos and Lukasz,
>>
>> This patchset adds more y2038 fixes that I would like to push for
>> 2.34. The first two patches enable more internal y2038 usage on glibc
>> and also for the installed programs.  Making glibc the first consumer
>> of these newer interfaces should improve coverage.
>>
> 
> Those two patches were already available for review for some time.
> Indeed, by using 64-bit time internally we may have more testing
> (sooner).

Yes, but I changed slight the one that enabled the y2038 symbol on
installed program to use apply the CFLAGS on module, instead of
setting in each sub Makefile.

> 
>> The next 6 patches removes an optimization I added on some specific
>> syscall, where a global variable it atomically set once glibc detects
>> that kernel supports 64-bit time.  The problem with this approach
>> breaks the usage case of live migration like CRIU or similar.
> 
> I do recall that this optimization was to avoid performance regression
> on legacy systems - to avoid issuing two syscalls (64 bit one and then
> 32 bit one).

Yes, but as I noted some interfaces don't really need to use the newer
syscall in the compatibility mode (where glibc is build to support older
kernels). This optimization is really tricky, since it incurs in some
data races (I think to fully avoid it would require seq-cst atomic instead
of relaxed ones) and it might break live migration.

> 
>>  Also
>> for some interfaces that do not query information from kernel, most
>> usages can be optimized away by either building glibc with a minimum
>> 5.1 kernel or by using the 32-bit syscall for the common case.
> 
> I do think that this approach (with classification of use cases based
> on specified kernel version) aligns with how people will build setups
> for those systems (at least I do it in this way for OE/Yocto).

I think there will be specific cases where kernel update is not an
option, but I think these will be really niches. 

> 
>>
>> So the following patch implement this optimization for the interfaces
>> that allows it.  If the provided timeout can be fit in old 32-bit
>> time_t, the old syscall is used instead.  This optimization is only
>> used for !__ASSUME_TIME64_SYSCALLS, otherwise the newer 64-bit
>> syscall are used.
> 
> Ok.
> 
>>
>> I checked this with 3 different configation which should cover most
>> usages:
>>
>>   - i686-linux-gnu on a 4.15 kernel and default --enable-kernel=3.2.
>>     This uses the 32-bit optimization to avoid calling the newer
>>     64-bit syscall when possible.  It also triggers and EOVERFLOW
>>     when 64-bit inputs are used without proper kernel support.
> 
> Ok.
> 
>>   - i686-linux-gnu on a 5.11 kernel and default --enable-kernel=3.2.
>>     This will also use the 32-bit optimization, but it will always
>>     succeded due proper kernel support.
> 
> Ok.
> 
>>   - i686-linux-gnu on a 5.11 kernel and with --enable-kernel=5.1.
>>     This enables __ASSUME_TIME64_SYSCALLS and only uses 64-bit
>>     time_t syscalls.
> 
> Ok.
> 
> BTW: I'm wondering when the minimal, supported Linux kernel version is
> going to be moved forward?

We usually follow the minimum LTS supported by Linux kernel developers.