Re: 2.25 freeze status

["H.J. Lu" <hjl dot tools at gmail dot com>]

On Mon, Jan 30, 2017 at 12:41 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> 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.

I have a couple questions:

1. Will this change be ever in 2.26?
2. Will this change be backported to 2.24?


-- 
H.J.