Re: 2.25 freeze status

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

On Mon, Jan 30, 2017 at 1:39 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> 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?
>

I don't think we should change anything for 2.25.  We know that when the
function is called, the program will crash.  If programmer is confident that
the function won't be called, he/she can create a private copy which calls
abort.  The program will start and abort if the function is called.


-- 
H.J.