[PATCH v3] elf: Release dl_load_lock before running dlopen constructors (BZ 15686)
Mikhail Novosyolov
m.novosyolov@rosa.ru
Tue Jul 21 14:17:24 GMT 2026
21.07.2026 16:25, Carlos O'Donell пишет:
> On 7/21/26 9:04 AM, Mikhail Novosyolov wrote:
>>
>> 21.07.2026 15:48, Carlos O'Donell пишет:
>>> On 7/21/26 8:29 AM, Alexander Pevzner wrote:
>>>> On 7/21/26 12:43 AM, Carlos O'Donell wrote:
>>>>> We might be able to run with this change downstream in Fedora and
>>>>> use our build infrastructure to do A/B build testing of the
>>>>> distribution to see if something comes out of the larger scale
>>>>> testing.
>>>>
>>>> BTW, I have tried the Artem's simple test on Fedora-44, and locking
>>>> is fully reproduceable there.
>>>
>>> The goal is to test much more of userspace to determine the impact of the
>>> change.
>>> With mass-prebuild (https://gitlab.com/fedora/packager-tools/mass-prebuild) we
>>> can build glibc with modifications into the COPR (default backend for mass
>>> prebuild) and then do the A/B (build and test) of thousands of packages as a
>>> proxy for finding issues.
>>
>> This patch fixes a runtime issue, not a compile-time one.
>>
>> A mass rebuild will show no new problems at build time.
>
> This would be true if we only ran the rpm %build phase, but we run more.
>
> When the mpb executes it will build the set of packages using the rpm
> infrastructure and that includes all of the packages running testing
> with %check after the rpm build phase.
>
> This means that an rpm mass-rebuild is a proxy for *runtime* quality
> and we use this proxy to determine impact.
I don't have exact numbers, but I think that a very small number of packages have %check
that dlopen's something and reaches this patched codepath.
>
> We likewise use mpb yearly to asses gcc rebases into Fedora ahead of
> integration to determine impact.
>
More information about the Libc-alpha
mailing list