This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 2.25 freeze status


On Mon, Jan 30, 2017 at 12:22 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/30/2017 02:39 PM, H.J. Lu wrote:
>> On Mon, Jan 30, 2017 at 11:17 AM, Carlos O'Donell <carlos@redhat.com> wrote:
>>> On 01/30/2017 02:04 PM, H.J. Lu wrote:
>>>>> H.J.,
>>>>>
>>>>> Could you please back out the fix for bug 20019?
>>>>>
>>>>> We will continue to try and fix this in 2.26 with a solution that moves
>>>>> IFUNC design towards a better documented set of semantics.
>>>>>
>>>>
>>>> Since calling longjmp will segfault in this case, shouldn't it be
>>>> fixed first by reverting IFUNC implementation in libpthread?
>>>
>>> I believe there is insufficient time to test that such a change and verify
>>> it does not have other unintended consequences for changing a symbol from
>>> IFUNC to non-IFUNC.
>>>
>>> The minimal fix is to revert the changes for bug 20019, and allow programs
>>> to startup, and run as expected in the cases they do not call longjmp.
>>>
>>> I would like to see the minimum amount of reversion required to get us
>>> back to a state where applications run again.
>>>
>>> We have only a few days until the release deadline and I do not wish
>>> to extend that date.
>>>
>>> I understand your desire to fix this correctly, and we will continue this
>>> discussion once master reopens, possibly with a reversion of the IFUNC
>>> change to libpthread.
>>
>> I don't think knowingly allow a program to segfault at random without any
>> warning is appropriate.  Can't we turn the fatal error into a non-fatal warning?
>
> What is or is not appropriate right now must be in the context of the upcoming
> release.
>
> The reversal of the patch is the simplist and most conservative move which
> restores the behaviour that allows programs to start.
>

I am not against allowing the bad programs to start.  But silently allow the
bad programs to crash at random isn't a conservative fix to me.

-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]