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

Yury Khrustalev yury.khrustalev@arm.com
Mon Mar 2 11:05:03 GMT 2026


On Fri, Feb 27, 2026 at 03:36:26PM -0300, Adhemerval Zanella Netto wrote:
> 
> On 21/02/24 20:47, DJ Delorie wrote:
> > 
> > The purpose of this change is twofold:
> > 
> > 1. The ld.so.cache is cached in memory and only re-read if/when
> >    it changes on disk.  This allows us to have much more intensive
> >    security checks in the future, without impacting performance as
> >    much.  It also allows for cases where the cache is corrupted -
> >    we continue using the last valid one.
> > 
> > 2. We break out the load/check logic so that the cache can be
> >    loaded independently of the library lookup, such as for
> >    code that only needs to look at the extensions.
> 
> I agree with Yury here that we need to add some tests, at least some
> minimal one that stress the ld.so.cache reload (which is not the usual
> scenario).  I would suggest add test-containts tests that:
> 
>   1. Construct a ld.so.cache, start the test, trigger ld.so.cache
>      reconstruct, and check if:
> 
>      1.1. A new entry is used on dlopen.
> 
>      1.2. If removing an entry triggers a dlopen failure.
> 
>      1.3. If not modifying the ld.so.cache contents keep the same
>           contents.
> 
>   2. Construct a ld.so.cache, start the test, create a invalid/corrupt
>      ld.so.cache and check if the test can load new libraries to
>      assure the cached load keeps working.

I appreciate that this is a feature creep which is of course not ideal,
however, this is important, so I'm happy to lend a hand to write these
tests. DJ, can we co-ordinate this between us?

Thanks,
Yury



More information about the Libc-alpha mailing list