Re: [PATCH v3] elf: Release dl_load_lock before running dlopen constructors (BZ 15686)

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 ([email protected])