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

21.07.2026 13:33, Florian Weimer:
> * Artem Proskurnev:
>
>> On the first two points, I think the framing is too narrow.
> The current patch is not backportable.  It's not clear if a future
> version, with more safeguards to preserve compatible behavior, will be
> backportable.  Would a fix in glibc 2.45 and future versions really
> solve the problem for you?
>
Two questions bundled here, with different answers.

== "Is the current patch backportable?"

https://abf.io/import/glibc/blob/rosa2023.1/glibc-elf-Release-dl_load_lock-before-running-dlopen-const.patch

https://abf.io/import/glibc/blob/rosa2023.1/glibc.spec#lc-123

In practice, yes.  ROSA is carrying v3 on top of glibc 2.40 in
our downstream tree right now -- the build that Mikhail Novosyolov
confirmed fixes ROSA bug 21031 (Codeblocks startup).  The patch
applies, the test suite passes modulo the pre-existing
environmental failures, and the reproducer stops deadlocking.

The complexity is real but contained: four files, about 90 lines
of production code, the rest is tests and documentation.  I would
not call it pleasant, but it is well within the range of what
distros backport for correctness fixes.  If your concern is that
no stable maintainer would accept this into a 2.40-ish stable
branch, that is a different claim from "not backportable" and
probably worth stating explicitly so we can discuss it.

By the way, AI does a very good job of adapting patches.
After adapting with AI, you have to do some manual work,
but AI can do most of the adaptation work.


== "Would a fix in 2.45 solve the problem for you?"

For ROSA's immediate deployment, the backport above already
solves it.  We are not blocked on upstream acceptance for our own
users.  Upstream acceptance in 2.45 would solve three problems
the backport does not:

1. Every glibc upgrade stops requiring us to rebase the patch.
    Right now ROSA owns this fix for as long as we ship a glibc
    derived from 2.40, and rebasing is real work each cycle.

2. Distributions without a glibc maintainer who can carry v3
    get the fix.  Right now every distro that ships glycin
    alongside recent gdk-pixbuf has the same regression and no
    path to a fix short of writing their own patch or waiting for
    upstream.  Most distros are in that second category.

3. The fix tracks changes in the loader as glibc evolves.  The
    dl_load_lock surface is not frozen -- BZ 28357 already
    reshaped parts of it, and more changes will come.  A fix in
    main has a chance to be maintained; a ROSA-only patch does
    not, and will eventually rot until the regression resurfaces
    in our next major rebuild.

If the project's answer is "this never lands upstream, distros
handle it", I can live with that.  We have a working backport and
we will carry it.  But that answer costs every other distro the
same work, and it costs ROSA the maintenance burden for as long
as we ship.  The reason I am pushing for upstream is to share
that burden, not because the backport does not work.

== What would make v3 easier to backport

If there is a shape the project would accept that is easier to
backport than v3, I am happy to produce it.  Concrete candidates
from my side:

- Drop the tunable (per the Carlos subthread).  Removes ~6 lines
   from dl-tunables.list and ~29 lines of texi documentation.
   Production code is unchanged.  This is the change most likely
   to actually help backportability, because it removes a new
   permanent API surface that stable maintainers are rightly
   cautious about.

- Drop the XFAIL test.  The test documents what v3 changes; if
   the project prefers to skip that documentation, the patch
   shrinks by about 200 lines across five files.  I would push
   back on this because the test is genuinely useful as a
   regression indicator for downstream, but it is a lever.

- Tighten comments.  117 comments for ~90 lines of code is heavy
   and I can compress the state-machine description if that is
   what is making the patch feel heavier than it is.

What I cannot drop without losing the fix itself is the state
machine in dl-init.c and dl-open.c.  That is the patch.

Thanks,
Artem