memcmp-sse4.S EqualHappy bug

[Dr. David Alan Gilbert]

* Torvald Riegel (triegel@redhat.com) wrote:
> On Thu, 2015-06-18 at 19:22 +0200, Andrea Arcangeli wrote:
> > On Thu, Jun 18, 2015 at 06:19:43PM +0200, Andrea Arcangeli wrote:
> > > workload.  That it can only return non zero is defined by the hardware
> > > and trivial to enforce in the workload of my testcase.
> > 
> > Instead of thinking in hardware terms, our colleague David (CC'ed)
> > suggested we can explain why there is a problem in C terms as well.
> > 
> > While the compiler would be free to reorder the load/stores if you
> > wrote the memcmp in C, and it would be free to duplicate a read, it
> > would never be free to terminate the comparison loop due any equal
> > result.
> 
> If there are data races, this is undefined behavior and *all* bets are
> off (according to the standard).  This includes results such as
> terminating the loop, stopping to do anything, etc.
> 
> This may seem overly drastic, but it's a useful line to draw because we
> don't want to have to reason based on details of a compiler's
> implementation.

Yes, I guess what I find interesting about this case is that:
   a) Having found a difference and then reread it and found it identical
    you *know* you've hit an 'undefined' case.

   b) The action taken in that case is an outcome that seems impossible
    from any memory reordering or pure-rereading of data; so it's more
    surprising than normal - people are already used to the compiler
    or the CPU reordering stuff, and having static mismatched data
    in the block would seem to be a guarantee that 0 could never
    happen.

   c) I worry if there's anything where a strcmp could get optimised
    into a memcmp and then hit this case, but I agree it's difficult to
    find a situation where it would have been safe anyway.

IMHO it would be safer to abort than to return 0, but that's probably
an equally controvercial result.

Dave
> 
--
Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK