-
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 (cherry picked from commit 53120279)
25818ac8
Validating GitLab CI configuration…
Learn more