This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


If I didn't understand your position correctly, please correct what I 
wrote so I can understand your suggestion.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]