[PATCH RESEND 0/3] elf: allow dl_iterate_phdr() to be called concurrently

[Caleb Sander Mateos]

On Wed, Sep 24, 2025 at 1:12 AM Florian Weimer <fweimer@redhat.com> wrote:
>
> * Caleb Sander Mateos:
>
> > Add support for (recursive) reader-writer locks in rtld, using
> > pthread_rwlock internally. Change dl_load_write_lock from a mutex to a
> > reader-writer lock to allow concurrent calls to dl_iterate_phdr().
> > _dl_add_to_namespace_list() and _dl_close_worker() acquire a write lock
> > as they modify the loaded object list, while __dl_iterate_phdr()
> > acquires a read lock as it only reads from the list.
>
> I think this change corrupts the libgcc_s unwinder cache in older GCC
> because it relies on the lock in dl_iterate_phdr to protect its internal
> cache.

Indeed, that's quite unfortunate. Feels like it would be better for
_Unwind_IteratePhdrCallback() to use a separate mutex to protect
access to frame_hdr_cache_head, but I wouldn't want to break it now.
My main complaint with the dl_iterate_phdr() mutex is that it appears
undocumented. If callers are allowed to depend on it (like libgcc_s)
or need to be aware of it to avoid deadlocks (like ThreadSanitizer),
it seems like an important behavior to document.
Another possible approach to prevent this deadlock would be on the
TSAN side, moving the dl_iterate_phdr() call to startup when no locks
are held. TSAN instruments each memory access and may take
TSAN-internal locks while handling it, so acquiring any external lock
from inside the TSAN handlers is a recipe for deadlock. The downsides
of unconditionally calling dl_iterate_phdr() at startup include a
delay in starting the application and increased memory consumption
(especially for large binaries or ones that link many shared objects).
The work could possibly be deferred to a background thread to avoid
blocking the application threads until a race report actually needs to
be produced. I'm not sure what appetite the TSAN folks would have to
implement something like this.

Best,
Caleb