Re: memcmp-sse4.S EqualHappy bug

[Rich Felker <dalias at libc dot org>]

On Wed, Jun 17, 2015 at 11:06:12PM +0200, Andrea Arcangeli wrote:
> On Wed, Jun 17, 2015 at 08:59:52PM +0200, Szabolcs Nagy wrote:
> > c11 has threads and a memory model that makes concurrency issues
> > observable in standard c.
> > 
> > however you have a data race that is undefined behaviour:
> > 
> > objects passed to memcmp are not supposed to be modified concurrently
> > without synchronization.
> 
> All right, I expected this was not a bug by the standard.
> 
> In my initial test code I had a contended pthread mutex at the start
> of the page that was passed to memcmp, I wasn't flipping bits myself,
> but I guess that's still undefined behavior if it's
> pthread_mutex_lock/unlock that are changing the memory passed to memcmp.
> 
> > that is unfortunate but i think your test code should be fixed.
> 
> That's ok, I already fixed it my test code after realizing the
> problem or it wouldn't run correctly on most x86-64 out there.
> 
> > (to avoid the observed behaviour the libc would have to guarantee
> > atomic memcmp which is nontrivial to do)
> 
> The end of the memory passed to memcmp is never changing and it is
> always different. I didn't expect an atomic behavior within the part
> of the page that is being changed, full atomicity is not to be
> expected and it was never provided by any version.

This is why undefined behavior is program-global (and in both space
and time). As soon as you invoke undefined behavior anywhere (e.g. a
data race), anything can happen, or can already have happened in the
past relative to point of UB.

Rich