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

[Lukasz Majewski]

Hi Adhemerval,

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

I've looked for such possibility, but the real issue IMHO is the
need to convert struct timespec to struct __timespec64 in functions
definitions/declarations.

In the end you would need to convert lll_futex_syscall() which need to
support __ASSUME_TIME64_SYSCALLS and futex_time64.
After this you are forced to convert all other pthread syscalls, which
use timeout argument.

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

Please see above comment - lowlevellock-futex.h written with C
preprocessor macros is the real issue here.

> 
> > 
> > 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 fully agree here - the code as proposed[1] - is rather not clean and
safe.

> I can help you on refactoring to code so
> the time64 changes should be simpler.

Ok. Thanks.

Now for instance we do have:

__pthread_mutex_clocklock_common (funcion) (pthread_mutex_timedlock.c)
    |
   \|/
  lll_timedwait (macro)          __lll_clocklock
    |                                 |
   \|/                               \|/
__lll_clocklock_wait   -> eligible for "conversion" Y2038 (function!)
lll_futex_timed_wait   -> (macro)
lll_futex_syscall      -> here is the call to futex syscall (macro)

The code itself has many levels with inline functions convoluted with
macros.

> 
> 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 think that this is not the case for most systems.

The 64 bit call for futex_time64 (and other 64 bit syscalls) were
introduced in Linux 5.1 - which is now more than a year ago.

The newest LTS Linux (5.4) now supports it - so it is likely that
new BSPs will use it. Especially, yocto LTS - dunfell (3.1) supports by
default 5.4 kernel.

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

I will share my comments on it in the patch itself.

> [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. 

I'm fine with postponing it as long as some work will be done in
parallel - the futex system call is crucial in many parts of glibc
library. Sooner we convert it and pull patches into glibc master, then
sooner it matures.


Links:
[1]
-https://patchwork.ozlabs.org/project/glibc/patch/20200707150827.20899-4-lukma@denx.de/


Best regards,

Lukasz Majewski

--

DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-59 Fax: (+49)-8142-66989-80 Email: lukma@denx.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20200714/75c3f314/attachment.sig>