[PATCH v3] elf: Release dl_load_lock before running dlopen constructors (BZ 15686)
Alexander Pevzner
pzz@apevzner.com
Mon Jul 20 17:12:51 GMT 2026
On 7/19/26 4:52 PM, Adhemerval Zanella Netto wrote:
> From the the reported deadlock, it doesn't really require releasing
> dl_load_lock around constructors at all. The actual blocking site is
> __cxa_thread_atexit_impl, which takes dl_load_lock only to look up the
> caller's link map. Replacing that lookup with the lock-free _dl_find_object
> removes the lock acquisition entirely.
The issue is actually more fundamental than that.
Because the current implementation holds a global lock during the entire
dlopen() operation, concurrent dlopen() calls are susceptible to
deadlocks. Specifically, if a constructor in the first thread tries to
synchronize or communicate with a second thread that is currently
blocked waiting for the dlopen() lock, a deadlock occurs.
While this application architecture is unusual, it is not prohibited by
POSIX or glibc documentation.
Replacing the lock in __cxa_thread_atexit_impl resolves this specific
instance, but it leaves the root architectural problem unfixed.
--
Wishes, Alexander Pevzner (pzz@apevzner.com)
More information about the Libc-alpha
mailing list