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

* Alexander Pevzner:

> Hi!
>
> On 7/13/26 8:43 AM, Florian Weimer wrote:
>
>> I believe this results in a data race on l_init_called.  In a
>> multi-threaded application, the same ELF constructor may execute with
>> itself in parallel on different threads, or dlopen may return before the
>> ELF constructor has completed running in another thread.  Some form of
>> synchronization is required to deal with these scenarios, perhaps using
>> pthread_once or a condition variable.
>
> I don't quite understand how could it happen. Constructors are running
> on a context of the thread that called dlopen, and should all complete
> before dlopen is finished and returned.

I expect that after your change, there is no synchronization that
protects the l_init_called update in call_init in elf/dl-init.c.

I think if you arrange for suitable sleeps or barriers, you can get a
second dlopen for the same object on another thread to return while the
constructor is still executing on a first thread.  This was not possible
before.

>> We also likely cannot remove a lock like this for old applications which
>> may depend on its existence.  We can deal with this with a different
>> mechanism.
>
> What visible change in behavior do you expect?

Two different DSOs access the same process-wide resource (say a global
variable in a third DSO, perhaps to register themselves) without
explicit synchronization.  Previously, this was safe due to the loader
lock.

Thanks,
Florian