Discussing blockers for glibc 2.34 release (50 days to ABI freeze).

Discussing blockers for glibc 2.34 release (50 days to ABI freeze).

[Carlos O'Donell]

In glibc 2.34 I would like to see the the following merged/complete/fixed:

(1) libpthread to libc merge.

(2) 64-bit time_t interface changes, but not a solution to utmp (which can happen later).

(3) pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing
    https://sourceware.org/bugzilla/show_bug.cgi?id=25847

(4) C.UTF-8 (later speed fixes optional)

My list is ambitious.

For (1) I'm trying to reivew the residual of Florian's patches at the end of each week.

When (1) is done I want to switch to reviewing Adhemerval's set of patches for (2).

I am prioritizing (1) and (2) over (3) and (4).

I'm hoping that Tulio might have time to review the recent suggestions in (3) and harmonize
some kind of solution.

I think (4) is almost complete thanks to Florian's review, after which we might be
able to implement some shortcuts to speed this up and minimize the required data.

What else should be on this list?

-- 
Cheers,
Carlos.

Re: Discussing blockers for glibc 2.34 release (50 days to ABI freeze).

[H.J. Lu]

On Wed, May 12, 2021 at 8:05 PM Carlos O'Donell <carlos@redhat.com> wrote:
>
> In glibc 2.34 I would like to see the the following merged/complete/fixed:
>
> (1) libpthread to libc merge.
>
> (2) 64-bit time_t interface changes, but not a solution to utmp (which can happen later).
>
> (3) pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing
>     https://sourceware.org/bugzilla/show_bug.cgi?id=25847
>
> (4) C.UTF-8 (later speed fixes optional)
>
> My list is ambitious.
>
> For (1) I'm trying to reivew the residual of Florian's patches at the end of each week.
>
> When (1) is done I want to switch to reviewing Adhemerval's set of patches for (2).
>
> I am prioritizing (1) and (2) over (3) and (4).
>
> I'm hoping that Tulio might have time to review the recent suggestions in (3) and harmonize
> some kind of solution.
>
> I think (4) is almost complete thanks to Florian's review, after which we might be
> able to implement some shortcuts to speed this up and minimize the required data.
>
> What else should be on this list?
>

I'd like to add the internal clone wrapper for clone, clone2, clone3.

-- 
H.J.

Re: Discussing blockers for glibc 2.34 release (50 days to ABI freeze).

[Siddhesh Poyarekar]

On 5/13/21 8:35 AM, Carlos O'Donell via Libc-alpha wrote:
> What else should be on this list?
> 

I want to take a stab at removing malloc hooks, but I'm not sure yet if 
I'll be able to get to it in time for 2.34 freeze.

Siddhesh

Re: Discussing blockers for glibc 2.34 release (50 days to ABI freeze).

[Carlos O'Donell]

On 5/12/21 11:20 PM, H.J. Lu wrote:
> On Wed, May 12, 2021 at 8:05 PM Carlos O'Donell <carlos@redhat.com> wrote:
>>
>> In glibc 2.34 I would like to see the the following merged/complete/fixed:
>>
>> (1) libpthread to libc merge.
>>
>> (2) 64-bit time_t interface changes, but not a solution to utmp (which can happen later).
>>
>> (3) pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing
>>     https://sourceware.org/bugzilla/show_bug.cgi?id=25847
>>
>> (4) C.UTF-8 (later speed fixes optional)
>>
>> My list is ambitious.
>>
>> For (1) I'm trying to reivew the residual of Florian's patches at the end of each week.
>>
>> When (1) is done I want to switch to reviewing Adhemerval's set of patches for (2).
>>
>> I am prioritizing (1) and (2) over (3) and (4).
>>
>> I'm hoping that Tulio might have time to review the recent suggestions in (3) and harmonize
>> some kind of solution.
>>
>> I think (4) is almost complete thanks to Florian's review, after which we might be
>> able to implement some shortcuts to speed this up and minimize the required data.
>>
>> What else should be on this list?
>>
> 
> I'd like to add the internal clone wrapper for clone, clone2, clone3.
 
Absolutely, we should cover all new linux syscalls where they make sense.

What other syscalls are there that we should include?

-- 
Cheers,
Carlos.

Re: Discussing blockers for glibc 2.34 release (50 days to ABI freeze).

[Carlos O'Donell]

On 5/12/21 11:34 PM, Siddhesh Poyarekar wrote:
> On 5/13/21 8:35 AM, Carlos O'Donell via Libc-alpha wrote:
>> What else should be on this list?
>>
> 
> I want to take a stab at removing malloc hooks, but I'm not sure yet if I'll be able to get to it in time for 2.34 freeze.

Yes, and that has security impact, but my last attempt got
hung up on the symbol versioning and exactly what we wanted
to remove.

See my last attempt in 2018:
https://sourceware.org/pipermail/libc-alpha/2018-June/095230.html

-- 
Cheers,
Carlos.

Re: Discussing blockers for glibc 2.34 release (50 days to ABI freeze).

[Adhemerval Zanella]

On 13/05/2021 09:55, Carlos O'Donell wrote:
> On 5/12/21 11:20 PM, H.J. Lu wrote:
>> On Wed, May 12, 2021 at 8:05 PM Carlos O'Donell <carlos@redhat.com> wrote:
>>>
>>> In glibc 2.34 I would like to see the the following merged/complete/fixed:
>>>
>>> (1) libpthread to libc merge.
>>>
>>> (2) 64-bit time_t interface changes, but not a solution to utmp (which can happen later).
>>>
>>> (3) pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing
>>>     https://sourceware.org/bugzilla/show_bug.cgi?id=25847
>>>
>>> (4) C.UTF-8 (later speed fixes optional)
>>>
>>> My list is ambitious.
>>>
>>> For (1) I'm trying to reivew the residual of Florian's patches at the end of each week.
>>>
>>> When (1) is done I want to switch to reviewing Adhemerval's set of patches for (2).
>>>
>>> I am prioritizing (1) and (2) over (3) and (4).
>>>
>>> I'm hoping that Tulio might have time to review the recent suggestions in (3) and harmonize
>>> some kind of solution.
>>>
>>> I think (4) is almost complete thanks to Florian's review, after which we might be
>>> able to implement some shortcuts to speed this up and minimize the required data.
>>>
>>> What else should be on this list?
>>>
>>
>> I'd like to add the internal clone wrapper for clone, clone2, clone3.
>  
> Absolutely, we should cover all new linux syscalls where they make sense.

Maybe the close_range [1] as well.

https://patchwork.sourceware.org/project/glibc/list/?series=2133

Re: Discussing blockers for glibc 2.34 release (50 days to ABI freeze).

[H.J. Lu]

On Thu, May 13, 2021 at 6:18 AM Adhemerval Zanella
<adhemerval.zanella@linaro.org> wrote:
>
>
>
> On 13/05/2021 09:55, Carlos O'Donell wrote:
> > On 5/12/21 11:20 PM, H.J. Lu wrote:
> >> On Wed, May 12, 2021 at 8:05 PM Carlos O'Donell <carlos@redhat.com> wrote:
> >>>
> >>> In glibc 2.34 I would like to see the the following merged/complete/fixed:
> >>>
> >>> (1) libpthread to libc merge.
> >>>
> >>> (2) 64-bit time_t interface changes, but not a solution to utmp (which can happen later).
> >>>
> >>> (3) pthread_cond_signal failed to wake up pthread_cond_wait due to a bug in undoing stealing
> >>>     https://sourceware.org/bugzilla/show_bug.cgi?id=25847
> >>>
> >>> (4) C.UTF-8 (later speed fixes optional)
> >>>
> >>> My list is ambitious.
> >>>
> >>> For (1) I'm trying to reivew the residual of Florian's patches at the end of each week.
> >>>
> >>> When (1) is done I want to switch to reviewing Adhemerval's set of patches for (2).
> >>>
> >>> I am prioritizing (1) and (2) over (3) and (4).
> >>>
> >>> I'm hoping that Tulio might have time to review the recent suggestions in (3) and harmonize
> >>> some kind of solution.
> >>>
> >>> I think (4) is almost complete thanks to Florian's review, after which we might be
> >>> able to implement some shortcuts to speed this up and minimize the required data.
> >>>
> >>> What else should be on this list?
> >>>
> >>
> >> I'd like to add the internal clone wrapper for clone, clone2, clone3.
> >
> > Absolutely, we should cover all new linux syscalls where they make sense.
>
> Maybe the close_range [1] as well.
>
> https://patchwork.sourceware.org/project/glibc/list/?series=2133

My clone wrapper for clone, clone2, clone3 is internal to glibc.  I
have implemented
the clone3 wrapper for i386:

https://gitlab.com/x86-glibc/glibc/-/commit/bb98bfdceba3cf02fee3e92cb3982a2148c67b0e#75c800b1b555cee39eb0c668df885cc9ac2550f0

and x86-64:

https://gitlab.com/x86-glibc/glibc/-/commit/53709bf596606f78a2b084d65bcde013dae0b00e#47f21603dbc7517b4b90fbb116b460751301f4bf

It is much simpler than the clone wrapper.   To add a public clone3 wrapper in
glibc 2.34, we need the clone3 wrapper for each target.

-- 
H.J.