Re: [PATCHv3] Protect _dl_profile_fixup data-dependency order [BZ #23690]

[Adhemerval Zanella <adhemerval dot zanella at linaro dot org>]

On 18/10/2018 10:39, Carlos O'Donell wrote:
> On 10/18/18 3:24 AM, Florian Weimer wrote:
>> * Carlos O'Donell:
>>
>>> The use of the guard+fence-to-fence sync is, from a C11 perspective,
>>> correct.
>>
>> I really don't think this is true:
>>
>> | Two expression evaluations conflict if one of them modifies a memory
>> | location and the other one reads or modifies the same memory location.
>>
>> (C11 5.1.2.4p4)
>>
>> | The execution of a program contains a data race if it contains two
>> | conflicting actions in different threads, at least one of which is not
>> | atomic, and neither happens before the other. Any such data race
>> | results in undefined behavior.
>>
>> (C11 51.2.4p25)
>>
>> We still have unordered conflicting non-atomic writes after Tulio's
>> patch.  I don't think they matter to us.  But this is *not* correct for
>> C11.
> 
> I agree completely. My point is that the change, the specific lines Tulio
> is touching, and the changes made, are correct, a fence-to-fence sync
> requires an atomic guard access. I agree it doesn't fix the actual problem
> of multiple threads doing the same updates to the reloc_result.
> 
> glibc is *full* of data races, and that doesn't mean we will just give up
> on using C11 semantics until we can fix them all. Any changes we do, we
> should do them so they are correct.
> 
> It really feels like we agree, but we're talking past eachother.  Did my
> previous email clarify our positions and which one I choose and why?
> 
> See:
> https://www.sourceware.org/ml/libc-alpha/2018-10/msg00320.html
> 
> If I didn't understand your position correctly, please correct what I 
> wrote so I can understand your suggestion.
> 

Wouldn't just disable lazy-resolution for LD_AUDIT be a simpler solution?
More and more distributions are set bind-now as default build option and
audition already implies some performance overhead (not considering the
lazy-resolution performance gain might also not represent true in real
world cases).