[PATCH 3/3] nptl: Only initialize robust list at mutex usage

[Adhemerval Zanella Netto]

On 08/09/25 13:34, Florian Weimer wrote:
> * Adhemerval Zanella:
> 
>>> Em 29 de jul. de 2025, à(s) 17:28, Florian Weimer <fweimer@redhat.com> escreveu:
>>>
>>> * Adhemerval Zanella:
>>>
>>>> The robust mutex kernel initialization is always performed at process
>>>> startup and thread creation, even when the process does not use any
>>>> robust mutexes.  This patch moves the set_robust_issue syscall to
>>>> either when a robust process is initialized or used, saving the
>>>> syscall issue for processes that do not use robust mutexes.
>>>>
>>>> The field futex_offset is used as a sentinel to indicate whether the
>>>> struct pthread list is already initialized.  This also allows to move
>>>> the __nptl_set_robust_list_avail from ld.so to libc.so, since there is
>>>> no need to initialize it at pthread startup.
>>>
>>> Why is this in optimization?  It adds a function call to the robust
>>> mutex locking path.
>>
>> Most process do not require robust mutexes, so it is one less syscall
>> per thread. And the function call is done once per thread, to setup
>> the syscall (the fast patch is done inline that checks the offset).
> 
> One side effect of the current implementation is that it's absolutely
> clear that glibc owns the robust list registration.  I think we should
> keep it like that, otherwise we need to write code and tests to deal
> with applications that use the robust list for their own purposes.

Nothing prevents an application to override an already set robust list
with a subsequent set_robust_list.  If the application is doing this,
it can not rely on pthread robust support from glibc.  So I am not
really convinced that this is an usercase we should care.