Skip to content
  • Michał Kępień's avatar
    Fix locking for LMDB 0.9.26 · 53120279
    Michał Kępień authored
    When "rndc reconfig" is run, named first configures a fresh set of views
    and then tears down the old views.  Consider what happens for a single
    view with LMDB enabled; "envA" is the pointer to the LMDB environment
    used by the original/old version of the view, "envB" is the pointer to
    the same LMDB environment used by the new version of that view:
    
     1. mdb_env_open(envA) is called when the view is first created.
     2. "rndc reconfig" is called.
     3. mdb_env_open(envB) is called for the new instance of the view.
     4. mdb_env_close(envA) is called for the old instance of the view.
    
    This seems to have worked so far.  However, an upstream change [1] in
    LMDB which will be part of its 0.9.26 release prevents the above
    sequence of calls from working as intended because the locktable mutexes
    will now get destroyed by the mdb_env_close() call in step 4 above,
    causing any subsequent mdb_txn_begin() calls to fail (because all of the
    above steps are happening within a single named process).
    
    Preventing the above scenario from happening would require either
    redesigning the way we use LMDB in BIND, which is not something we can
    easily backport, or redesigning the way BIND carries out its
    reconfiguration process, which would be an even more severe change.
    
    To work around the problem, set MDB_NOLOCK when calling mdb_env_open()
    to stop LMDB from controlling concurrent access to the database and do
    the necessary locking in named instead.  Reuse the view->new_zone_lock
    mutex for this purpose to prevent the need for modifying struct dns_view
    (which would necessitate library API version bumps).  Drop use of
    MDB_NOTLS as it is made redundant by MDB_NOLOCK: MDB_NOTLS only affects
    where LMDB reader locktable slots are stored while MDB_NOLOCK prevents
    the reader locktable from being used altogether.
    
    [1] https://git.openldap.org/openldap/openldap/-/commit/2fd44e325195ae81664eb5dc36e7d265927c5ebc
    53120279
Validating GitLab CI configuration… Learn more