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

https://patchwork.sourceware.org/patch/139350

The single regression reported by Linaro TCWG CI on both aarch64 and arm 
is XPASS: nptl/tst-create4. This test is
intentionally marked XFAIL in the patch (test-xfail-tst-create4 = yes) 
because it verifies the non-interleave property that this
patch deliberately removes: with the patch, constructors of independent 
DSOs loaded from different threads can interleave. An
XPASS on some runs is expected flaky behaviour for a test that documents 
a removed property; it does not indicate a real regression.
No PASS->FAIL transitions are reported on either architecture. The 
97/111 ‘fixes’ are environment-driven (no cgroupv2, no /dev/fuse,
no root in CI container). An x86_64 make check run under identical 
conditions on both sides shows 0 patch-attributable transitions.

> A third test, tst-create4/tst-create4mod-a/tst-create4mod-b,
> documents a property that the patch removes: under the pre-BZ-15686
> locking model, dl_load_lock serialised the entire _dl_open across
> threads, so constructors of independent DSOs loaded from different
> threads could not interleave.  After the patch, they can.  The test
> asserts the OLD non-interleaving behaviour and is therefore marked
> XFAIL via test-xfail-tst-create4 = yes.  It is included as a
> diagnostic tool for downstream applications that may have implicitly
> relied on the old total order -- plugin registries whose registration
> order determined behaviour, signal-handler chains installed in
> constructors, global logger/telemetry setup, etc.
>