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

[Carlos O'Donell]

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?

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

-- 
Cheers,
Carlos.