From owner-freebsd-threads@freebsd.org Tue Jun 16 21:55:08 2020 Return-Path: Delivered-To: freebsd-threads@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 12ACE3366CA for ; Tue, 16 Jun 2020 21:55:08 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49mhnl6lcTz3YH6 for ; Tue, 16 Jun 2020 21:55:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id E7899336914; Tue, 16 Jun 2020 21:55:07 +0000 (UTC) Delivered-To: threads@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E74F43367A9 for ; Tue, 16 Jun 2020 21:55:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.nyi.freebsd.org (mxrelay.nyi.freebsd.org [IPv6:2610:1c1:1:606c::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mxrelay.nyi.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49mhnl5wZfz3YH5 for ; Tue, 16 Jun 2020 21:55:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2610:1c1:1:606c::50:1d]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mxrelay.nyi.freebsd.org (Postfix) with ESMTPS id A98211603B for ; Tue, 16 Jun 2020 21:55:07 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.5]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id 05GLt7W9071624 for ; Tue, 16 Jun 2020 21:55:07 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id 05GLt7Oq071623 for threads@FreeBSD.org; Tue, 16 Jun 2020 21:55:07 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: threads@FreeBSD.org Subject: [Bug 244493] databases/lmdb: issue with MDB_USE_POSIX_MUTEX Date: Tue, 16 Jun 2020 21:55:07 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Ports & Packages X-Bugzilla-Component: Individual Port(s) X-Bugzilla-Version: Latest X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: delphij@FreeBSD.org X-Bugzilla-Flags: maintainer-feedback? 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: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 21:55:08 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D244493 --- Comment #2 from commit-hook@freebsd.org --- A commit references this bug: Author: delphij Date: Tue Jun 16 21:54:59 UTC 2020 New revision: 539380 URL: https://svnweb.freebsd.org/changeset/ports/539380 Log: MFH: r539379 databases/lmdb: in db_env_close0(), destroy robust mutexes if we are the only remaining user. When closing an lmdb database, all memory and file descriptor resources are released, including the shared memory pages that contained the robust mutex. However, before this commit, prior to unmapping the pages that contained the robust mutexex, lmdb did not destroy the mutexes first. This would create a problem when an application opens and closes a database, then open it again. According to libthr(3), by default, a shared lock backed by a mapped file in memory is automatically destroyed on the last unmap of the corresponding file' page, which is allowed by POSIX. After unmapping the shared pages, the kernel writes off all active robust mutexes associated with these pages. However, the userland threading library still keeps the record (pshared_lookup in thr_pshared.c of libthr) for these objects as they are not really destroyed before, so that it don't have to ask the kernel every time when looking them up. Now, a later re-open of the database might have mapped the lock file to the same memory location. Because the threading library have remembered the robust mutex object, it would just reuse it even though it was already invalid from kernel's point of view. Unfortunately, regular lock operations would still work for this process. Should another lmdb process opens the same database, it would attempt to obtain the robust mutex (no longer recognized by kernel) because it would see another process holding a file lock, but that would fail because the robust mutex is invalid for the kernel. Explicitly destroy the mutex if we are the last remaining user to ensure the mutex is always in a known defined state. OpenLDAP ITS #9278 With debugging help from: kib PR: 244493 Approved by: ports-secteam Changes: _U branches/2020Q2/ branches/2020Q2/databases/lmdb/Makefile branches/2020Q2/databases/lmdb/files/patch-mdb.c --=20 You are receiving this mail because: You are on the CC list for the bug.=