[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 #10 from Noah Goldstein <goldstein.w.n at gmail dot com> ---
(In reply to Noah Goldstein from comment #9)
> (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.

Out of curiosity what is the use-case that causes this to happen? Is it
idiomatic in some way?

I'm unhappy that the code causes a SIG-11 in this case, but changing
it to harden against this case is not free for correct usage performance
so I'm not really convinced it's worth supporting this buggy usage unless
this bug is common to some idiomatic schema (although even then, I'm not
sure whether we could harden the entire string/mem library to that
usage or even what changes that would imply).

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