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

[Mikhail Novosyolov]

21.07.2026 14:03, Artem Proskurnev пишет:
> 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. 
<...>
>
> == "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. 

For us (Artem and me), as a distro, it is not a problem to carry a backport in an older version, where we need it.

It is up to you to decide if this has to be backported to release/2.4x/master or not.
I think here, due to potential regressions, better avoid a backport.