[Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change

["goldstein.w.n at gmail dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=29863

--- Comment #9 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to K.S. Bhaskar from comment #8)
> (In reply to Andrew Pinski from comment #6)
> > (In reply to Narayanan Iyer from comment #5) 
> > > Seems to me you are saying that `memcmp()` can only be called on memory that
> > > is guaranteed to be never changing. And that it should never be called on a
> > > shared memory buffer whose contents could be concurrently changing as it
> > > goes into undefined behavior territory. That does not sound right to me as
> > > we have been using `memcmp()` with shared memory (where multiple processes
> > > write to that memory buffer all the time) for the past 25+ years on a
> > > variety of architectures and operating systems and have never once seen a
> > > SIG-11 in memcmp().
> > 
> > That does not mean it is correctly well defined code.
> > memcmp cannot be used on memory which is going to be changed under its back.
> > since it is not atomic.
> 
> Since memcmp() is not atomic, it is of course appropriate for the the
> results of the comparison to have a race condition. However, since the
> addresses by which a process has that memory mapped don't change, a SIG-11
> should never occur. Even if all other processes which have that memory
> mapped terminate while the memcmp() is running in a process, that process
> will not unmap the memory and it will remain valid (assuming it was valid to
> start with).

memcmp() is incorrect if the values change from under it. How that
incorrectness will manifest is completely undefined.

-- 
You are receiving this mail because:
You are on the CC list for the bug.