From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id DA4B13838F0B; Tue, 13 Dec 2022 20:46:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org DA4B13838F0B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1670964361; bh=2C+YtAkbkdkGfbvAQQdmuqARXMPtdjZtyBZ0DmpKaIw=; h=From:To:Subject:Date:In-Reply-To:References:From; b=veTKOFxh8J7F4TnstAbM/DVNBy92f0txRbn87pj540JeJn4DZhsmEEMlMRBgY/PtJ K1IY/pSccoxtpHku0TgCNHkGulkBV0xoUbo54Q0y8bnUaxp2l40WWcoV1I5DLVtkJj fi4tSgjnCfxAttPvzFxnAU7qR1MTzOfkB6kZ+zCE= From: "nars at yottadb dot com" To: glibc-bugs@sourceware.org Subject: [Bug libc/29863] Segmentation fault in memcmp-sse2.S if memory contents can concurrently change Date: Tue, 13 Dec 2022 20:46:01 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Version: 2.36 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: nars at yottadb dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D29863 --- Comment #11 from Narayanan Iyer --- (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? >=20 > 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 cont= rol (also known as OCC) to implement transaction processing. See https://en.wikipedia.org/wiki/Optimistic_concurrency_control for more detai= ls. 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 s= ince 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, V= AX, Sparc, HPPA etc.) and operating systems (Linux, AIX, Tru64, Solaris, HPUX e= tc.) 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 ab= ove, there are a lot of databases that use OCC. It is likely all of them use sim= ilar techniques and are affected as well. --=20 You are receiving this mail because: You are on the CC list for the bug.=