[Bug 244493] databases/lmdb: issue with MDB_USE_POSIX_MUTEX

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Tue Jun 16 21:55:08 UTC 2020


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493

--- Comment #2 from commit-hook at 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

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


More information about the freebsd-threads mailing list