Re: Upcoming glibc 2.33 freeze in 2 weeks.

Re: Upcoming glibc 2.33 freeze in 2 weeks.

[Romain GEISSLER]

> Le 3 janv. 2021 à 14:12, Carlos O'Donell via Libc-alpha <libc-alpha sourceware ! org> a écrit :
> 
> Your patches are an important change and we should get to
> reviewing them again this release.
> 
> Florian has fixed a number of important issues in the loader
> that make me less worried about corner cases with NODELETE,
> audit loading, and early startup sequencing.
> 
> Florian has assigned himself for review of the v3 patches
> (delegate in patchwork). Him and I discussed this patch set
> specifically. I see v4 in patchwork now, thanks!
> 
> -- 
> Cheers,
> Carlos.

Hi,

FYI, we (Amadeus) are very glad with the work by Chung Lin done in these patch proposal. It happens that the problems described in the different bugzilla did happen internally in one very specific backend server application in Amadeus (just one application out of tens of thousands existing, yet this one is definitely at the core of our business, so it had to be fixed one way or another). In may 2020, following a migration from an even older glibc to glibc 2.23, we did hit performance problem with a large number of DSO loaded (order of magnitude: about 1000 shared libraries) having unusual dependencies and coupled with many manual dlopens (to be honest, I haven’t even tried understood what is so specific about this application). I (tried to) backport this patch the best I can to the years old glibc 2.23, and for this specific application, it did fix their issues (it’s running in production one thousands on servers since roughly 6 months).

In addition to that, in the latest version of the Amadeus C++ middleware, which is right now not loaded in production with any significative numbers to be meaningful, but still used daily for now just in development environment by a small subset of our teams (let’s say about 100 C++ developers in Amadeus working mainly on middleware, partially in final backend applications), these patches, applied on glibc 2.32 and enabled by default have not created any issue that we could notice. Yet, we definitely have a rather simple DSO usage (and usually homogenous), much simpler than what can be found in all the open source packages of a linux distro.

Anyway, my point was: we are partially running backport of these patches in production or these exact patches in development environment since 6 months, and we haven’t noticed any impact (except of course fixing our DSO loading/unloading performance problems).

Cheers,
Romain

Re: Upcoming glibc 2.33 freeze in 2 weeks.

[Carlos O'Donell]

On 1/3/21 6:36 AM, Chung-Lin Tang wrote:
> 
> 
> On 2020/12/22 11:54 PM, Carlos O'Donell via Libc-alpha wrote:
>> This is reminder that the development branch will freeze in
>> approximately 2 weeks.
>>
>> After that point you will need to discuss inclusion with
>> Adhemerval Zanella, who has kindly volunteered to be the
>> release manager for 2.33.
>>
>> All of January is dedicated to stabilizing development with
>> bug fixes and corrections to any ABIs that are currently
>> committed.
>>
>> The next public patch review meeting is on January 4th 2021
>> and my focus will be on patches that need review for the
>> release.
>>
> 
> I have added my patches for fixing the #17645 DSO sorting algorithm issues as blocker.
> 
> I'm not sure if they're important enough, but this patch has almost gotten approval
> but was deemed too late in the release cycle, twice in the past year I think.
> Hope it gets through this time.

Your patches are an important change and we should get to
reviewing them again this release.

Florian has fixed a number of important issues in the loader
that make me less worried about corner cases with NODELETE,
audit loading, and early startup sequencing.

Florian has assigned himself for review of the v3 patches
(delegate in patchwork). Him and I discussed this patch set
specifically. I see v4 in patchwork now, thanks!

-- 
Cheers,
Carlos.

Re: Upcoming glibc 2.33 freeze in 2 weeks.

[Chung-Lin Tang]

On 2020/12/22 11:54 PM, Carlos O'Donell via Libc-alpha wrote:
> This is reminder that the development branch will freeze in
> approximately 2 weeks.
> 
> After that point you will need to discuss inclusion with
> Adhemerval Zanella, who has kindly volunteered to be the
> release manager for 2.33.
> 
> All of January is dedicated to stabilizing development with
> bug fixes and corrections to any ABIs that are currently
> committed.
> 
> The next public patch review meeting is on January 4th 2021
> and my focus will be on patches that need review for the
> release.
> 

I have added my patches for fixing the #17645 DSO sorting algorithm issues as blocker.

I'm not sure if they're important enough, but this patch has almost gotten approval
but was deemed too late in the release cycle, twice in the past year I think.
Hope it gets through this time.

Thanks,
Chung-Lin

Re: Upcoming glibc 2.33 freeze in 2 weeks.

[Adhemerval Zanella]

On 28/12/2020 18:32, Jim Wilson wrote:
> On Tue, Dec 22, 2020 at 7:55 AM Carlos O'Donell via Libc-alpha <
> libc-alpha@sourceware.org> wrote:
> 
>> The next public patch review meeting is on January 4th 2021
>> and my focus will be on patches that need review for the
>> release.
>>
> 
> riscv64-linux has ~50 make check failures using top of tree binutils and
> gcc, of which ~30 are ifunc related.  This is because we have upstreamed
> the binutils and gcc ifunc support, but the glibc ifunc support isn't in
> yet.  Vincent Chen posted the v2 riscv ifunc patches about 2 weeks ago.  It
> would be nice to get those in.  With those patches in we have ~20
> failures.  Otherwise, we might need workarounds to get below 25 failures.
> 
> Jim
> 

I have added them on 2.33 release blockers [1].  I hope next week once
we can sort this and other releases blocker on the weekly patch review
call.

[1] https://sourceware.org/glibc/wiki/Release/2.33#preview

Re: Upcoming glibc 2.33 freeze in 2 weeks.

[Jim Wilson]

On Tue, Dec 22, 2020 at 7:55 AM Carlos O'Donell via Libc-alpha <
libc-alpha@sourceware.org> wrote:

> The next public patch review meeting is on January 4th 2021
> and my focus will be on patches that need review for the
> release.
>

riscv64-linux has ~50 make check failures using top of tree binutils and
gcc, of which ~30 are ifunc related.  This is because we have upstreamed
the binutils and gcc ifunc support, but the glibc ifunc support isn't in
yet.  Vincent Chen posted the v2 riscv ifunc patches about 2 weeks ago.  It
would be nice to get those in.  With those patches in we have ~20
failures.  Otherwise, we might need workarounds to get below 25 failures.

Jim

Upcoming glibc 2.33 freeze in 2 weeks.

[Carlos O'Donell]

This is reminder that the development branch will freeze in
approximately 2 weeks.

After that point you will need to discuss inclusion with
Adhemerval Zanella, who has kindly volunteered to be the
release manager for 2.33.

All of January is dedicated to stabilizing development with
bug fixes and corrections to any ABIs that are currently
committed.

The next public patch review meeting is on January 4th 2021
and my focus will be on patches that need review for the
release.

-- 
Cheers,
Carlos.