[PATCH 2/3] Add system-wide tunables: cache ld.so.cache

[Adhemerval Zanella Netto]

On 20/06/24 16:08, Carlos O'Donell wrote:
> On 6/19/24 8:52 AM, Adhemerval Zanella Netto wrote:
>>
>>
>> On 29/05/24 14:15, DJ Delorie wrote:
>>> Adhemerval Zanella Netto <adhemerval.zanella@linaro.org> writes:
>>>> It is not clear to me why we need the load/reload support for ld.so.cache
>>>> to support system-wide tunables.
>>>
>>> It's kinda independent.  Carlos requested it to benefit long-running
>>> processes that call dlopen() regularly, to get updates to search paths.
>>> The tunables code takes advantage of the refactoring to make sure the
>>> cache is loaded when needed, since tunables happens before DSOs.
>>
>> But currently we do not catch ld.so.cache, it is mmap'ed on process start
>> and unmmap'ed at the end of DT_NEEDED process (elf/rtld.c:2402).  The same
>> process is done on dlopen (elf/dl-open.c:909), so any update done by ldconfig
>> will be seem on any subsequent dlopen.
> The cache, while continuously mapped, is only updated by ldconfig with a rename:
> 
>  733   /* Move temporary to its final location.  */
>  734   if (rename (temp_name, cache_name))
>  735     error (EXIT_FAILURE, errno, _("Renaming of %s to %s failed"), temp_name,
>  736            cache_name);
> 
> Therefore the old file remains, unlinked from the filesystem, and backing the mapping.
> 
> An atomic rename is the only sensible thing to do in this case, we have no guarantee that any
> process on the system is in any state to traverse the file mapping while it is being updated.
> 
>> There is still a small window where either a new process is starting of dlopen
>> is accessing the ld.so.cache contents and ldconfig is doing the final rename 
>> of a new cache, but trying to synchronize it would require a more complex
>> way (most likely either by making the ld.so.cache private or mapping is a
>> shared memory and doing some synchronization).
>  
> May you please explain the race in more detail?

Nevermind, for some reason I have a mental model that open and mmap could
race during concurrent ldconfig/symbol resolution; but kernel should not 
allow it.

> 
> In summary: We need to detect the file change and reload the cache.
> 

Right, but I am still not really sure if this is really an improvement.
On program startup and dlopen, it would make DT_NEEDED libraries 
potentially see different cache state (since _dl_map_object will be 
called for each dependency) which I am not really sure how safe and
robust it would be.  

I would expect that for both program loading and each ldopen, the
cache state used for libraries resolution to be the same.