Re: [PATCH v3] elf: Release dl_load_lock before running dlopen constructors (BZ 15686)
Mikhail Novosyolov <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha |
|---|---|
| Message-ID | <[email protected]> |
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. >