memcmp-sse4.S EqualHappy bug

[Ondřej Bílka]

On Fri, Jun 19, 2015 at 04:59:08PM +0100, Dr. David Alan Gilbert wrote:
> * Torvald Riegel (triegel@redhat.com) wrote:
> > On Fri, 2015-06-19 at 10:42 -0400, Simo Sorce wrote:
> > > On Fri, 2015-06-19 at 16:07 +0200, Andrea Arcangeli wrote:
> > > > On Fri, Jun 19, 2015 at 09:38:51AM -0400, Carlos O'Donell wrote:
> > > > > I agree with aborting, but only as long as the hot path's performance
> > > > > is not impacted and I haven't thought about how to do that.
> > > > > 
> 
> > > Clearly people are better using atomic comparisons on canary values
> > > instead, but it seem easy to avoid false positives (returning 0 when
> > > memory is clearly different) and keep these things working, so why not
> > > do it ?
> > 
> > I see two separate issues here.  First, where do we draw the line, and
> > what do we guarantee.  I strongly believe that programs must not have
> > data races, and that they should use atomics or other synchronization
> > properly (this doesn't mean locks, but relaxed memory order atomics, for
> > example).
> > Second, do we try to keep buggy programs working.  If it has no cost to
> > do so (e.g., like it might be true in this case), then doing that can
> > help to trigger less errors.  But that doesn't mean the buggy programs
> > should get fixed eventually.
> 
> I find it difficult to understand the boundaries of what the C library
> is allowed to do in this type of optimisation.
> 
> For example, consider the following:
> 
>     char a[128];
>     char b[128];
> 
>     put some static data in a[0-63]
>     put some static data in b[0-63]
>     a[64]=0;
>     b[64]=0;
>     start a thread doing stuff in a[65..]
>     start a thread doing stuff in b[65..]
>     
>     if (!strcmp(a,b)) {
>       /* Do something */
>     }
> 
>    a) Is that behaviour defined?
>    b) Is it defined with strncmp(a,b,64) ?
>    c) Is it defined with strncmp(a,b,128)?
>    d) Is it defined with memcmp(a,b,64)?
>    e) Is it defined with memcmp(a,b,128)?
>    f) If I moved that boundary off a nice round % 8 mark would
>       it matter?
>
Yes, this is correct as memory is indistingushible from using

struct foo
{
  char start[65];
  char end[63];
}

where end is modified in parallel.

Only thing that could differ is performance as we read past end as long
as it doesn't cross page, then discard data after end.