Re: 2.25 freeze status

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

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?)

-- 
Cheers,
Carlos.