Re: 2.25 freeze status

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

On Tue, Jan 31, 2017 at 10:59 AM, Carlos O'Donell <carlos@redhat.com> wrote:
> On 01/31/2017 10:57 AM, H.J. Lu wrote:
>> 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.
>
> I disagree, and consensus appears to be so far to revert your patch until we
> can resolve this discussion.
>
> Is your position an objecting position? Would you object to the reversion of
> your patch for 2.25 until we can work out a better solution?
>
> In favor of reverting:
> Carlos O'Donell, Florian Weimer, Phil Blundell.
>
> Not in favor of reverting:
> H.J. Lu (non-objecting?)
>

I object.


-- 
H.J.