Hello!

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.

Thanks!

17.07.2026 23:53, ci_notify@linaro.org:

Dear contributor,

Our automatic CI has detected problems related to your patch(es). Please find some details below.

In glibc_check master-arm, after: | glibc patchhttps://patchwork.sourceware.org/patch/139350 | Author: Artem Proskurnevtemap@mail.ru | Date: Thu Jul 16 19:04:01 2026 +0300 | | [PATCH v3] elf: Release dl_load_lock before running dlopen constructors (BZ 15686) | | This addresses one instance of the long-standing class of deadlocks | described in BZ #15686: ELF constructors and destructors invoked by | the dynamic loader run with dl_load_lock held, so any code path in | ... 232 lines of the commit log omitted. | ... applied on top of baseline commit: | a29c483d3c Add RWF_NOSIGNAL from Linux 6.18 to bits/uio-ext.h

Produces 1 regression 111 fixes: | | regressions.sum: | Running glibc:nptl ... | XPASS: nptl/tst-create4 | | fixes.sum: | Running glibc:debug ... | FAIL: debug/tst-fortify-syslog | ... and 125 more

Used configuration : *CI config* tcwg_glibc_check master-arm *configure and test flags:* none, autodetected on armv8l-unknown-linux-gnueabihf

If you have any questions regarding this report, please ask onlinaro-toolchain@lists.linaro.org mailing list.

-----------------8<--------------------------8<--------------------------8<--------------------------

The information below contains the details of the failures, and the ways to reproduce a debug environment:

You can find the failure logs in *.log.1.xz files in *http://54.172.246.49:9090/jobs/tcwg_glibc_check--master-arm-precommit/builds... The full lists of regressions and improvements as well as configure and make commands are in *http://54.172.246.49:9090/jobs/tcwg_glibc_check--master-arm-precommit/builds... The list of [ignored] baseline and flaky failures are in *http://54.172.246.49:9090/jobs/tcwg_glibc_check--master-arm-precommit/builds...

Current build :http://54.172.246.49:9090/jobs/tcwg_glibc_check--master-arm-precommit/builds... Reference build :http://54.172.246.49:9090/jobs/tcwg_glibc_check--master-arm-build/builds/103...

Warning: we do not enable maintainer-mode nor automatically update generated files, which may lead to failures if the patch modifies the master files.