[RFC 00/10] y2038: nptl: futex: Provide support for futex_time64

[Adhemerval Zanella]

On 07/07/2020 12:08, Lukasz Majewski wrote:
> Please find this early RFC for converting 'futex' syscall based code
> (pthreads/nptl/sem/gai) to support 64 bit time.
> When applicable the futex_time64 syscall is used.
> 
> The main purpose of this RFC is to assess if taken approach for conversion is
> correct and acceptable by the glibc community.
> 
> Quesitons/issues:
> 
> 1. This whole patch set shall be squashed into a single patch, otherwise, the
> glibc will not build between separate commits. I've divided it to separate
> patches on the purpose - to facilitate review.

Another possibility could to work by adjusting each symbol and the required
futex_* / lll_lock machinery instead.  For instance, add 64-bit time_t
support pthread_mutex_{timed,clock}lock, which in turn required to adjust
futex_lock_pi/lll_futex_timed_wait/lll_futex_clock_wait_bitset.

In this way we can tests the change better since they are incremental.

> 
> 2. Question about rewritting lll_* macros in lowlevel-*.h - I'm wondering if
> there is maybe a better way to do it. Please pay attention to the *_4 suffix.

For lll_* I really think we should convert them to proper inline function
instead, the required code change to adjust the macro is becoming really
convoluted. I can help you on refactoring to code so the time64 changes
should be simpler.

Also, futex is a syscall used extensively and I think we should optimize 
the fallback code to avoid issue the 64-bit time one if the kernel
does not support it (as we do for clock_gettime).

I have send a patchset with some y2038 fixes and I added a generic support
to simplify it [1]. We will probably need some adjustments to make it
work on libpthread.

[1] https://sourceware.org/pipermail/libc-alpha/2020-July/116259.html

> 
> 3. What would be the best point in the glibc release cycle to apply this patch
> set as it convets the core functionality of the library?
> 
> Just after the stable release?

I think it is late for 2.32, we should postpone it to 2.33.