Re: 2.25 freeze status

[Carlos O'Donell <carlos at redhat dot com>]

On 01/30/2017 03:38 PM, H.J. Lu wrote:
> 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.
 
It isn't a fix at all. We have run out of time to address the issue, and for
the upcoming 2.25 release it would be better that the applications continue
with their existing behaviour, rather than new behaviour that we know we
have to change again.

-- 
Cheers,
Carlos.