Re: memcmp-sse4.S EqualHappy bug

["Dr. David Alan Gilbert" <dgilbert at redhat dot com>]

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

I can imagine there may be lots of things that terminate
a string and let other stuff happen in the allocated space
after the end of the string in the belief that at the end
of that string all is unknown.   Andrea's case is a bit different
in that it's the later data that's static, but that doesn't
sound like it should change the answer as to what's allowed.

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