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

["nars at yottadb dot com" <sourceware-bugzilla@sourceware.org>]

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

--- Comment #11 from Narayanan Iyer <nars at yottadb dot com> ---
(In reply to Noah Goldstein from comment #10)

> 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).

We implement a database called YottaDB. It uses optimistic concurrency control
(also known as OCC) to implement transaction processing. See
https://en.wikipedia.org/wiki/Optimistic_concurrency_control for more details.

Every process that is in a transaction reads database values (from shared
memory) without holding a lock and tentatively prepare the needed changes in
private memory. To do this, it needs to examine shared memory contents and it
is here that we do the `memcmp()` calls which ended up with a SIG-11.

At the end of the transaction, we grab a lock and see if anything changed since
we started the transaction and if not we proceed to commit. If we notice
something changed, we restart the transaction. We minimize the use of locks
using this approach to get faster transaction throughput.

As I had mentioned in a previous comment, this model has been in use by us for
the past 25+ years in various architectures (x86_64, i386, RS6000, Alpha, VAX,
Sparc, HPPA etc.) and operating systems (Linux, AIX, Tru64, Solaris, HPUX etc.)
and has never caused a SIG-11 until now (i.e. glibc 2.36).

As you can see in the `Examples` section of the wikipedia link I mention above,
there are a lot of databases that use OCC. It is likely all of them use similar
techniques and are affected as well.

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