To prevent any conflict in the future, avoid ldap_ prefix in any
internal functions. Keep it reserved for openldap only.
(cherry picked from commit 7bce3e7791)
ldap_connect is defined by OpenLDAP 2.6. Compiler complains there are
conflicting declarations. Use dlz_ldap prefix instead of ldap to avoid
conflict.
(cherry picked from commit 49e523e56f)
Commit e8d8b43e dropped dependency of "respdiff" and
"respdiff-third-party" jobs on "tarball-create" job because these jobs
don't need to depend on in (e.g., for its artifacts). This, however,
caused that respdiff jobs weren't started out-of-order and artifacts
from all the "Build" stage jobs plus "unit:gcc:buster:amd64" job were
downloaded to project directory and caused problems with compilation:
Originally, the dependency on "tarball-create" has been added in
704eeb32 to indicate that respdiff "is meant to operate on two different
BIND versions". It seems that the intent didn't work out, and we better
make it obvious that respdiff jobs don't depend on any other job and
should be run out-of-order.
(cherry picked from commit 87578efc71)
The order of directories with reference and test BIND 9 are now reversed
for respdiff.sh.
The data.mdb file has more than 10 GB and makes artifact download take
an unnecessarily long time.
(cherry picked from commit 2ececf2c02)
Support for FreeBSD 11.4, the last FreeBSD 11.x release, ended on
September 30, 2021.
The "--with-readline" ./configure option has been added to gcc:sid:amd64
CI job; otherwise, it would be lost with the FreeBSD 11 removal.
Link: https://www.freebsd.org/security/unsupported/
(cherry picked from commit 981579f379)
For small sized allocations, the internal allocator gets the memory in
bigger blobs that gets splits into right-sized chunks. This increases
speed of small allocations and reduced the fragmentation, but such
memory is never released back to the operating system.
Disable the internal allocator by default, and add new `-M internal`
command line option to `named`.
Previously, with BIND 9 internal allocator, when isc_mempool_put() would
return memory to the allocator, it would not be freed, but it would be
returned to the "freelists" and the memory would not be released to the
operating system.
Change the isc_mempool_get() and isc_mempool_put() to avoid the internal
allocator (mem_getunlocked() and mem_putunlocked()).
According to the measurements (recorded on GL!5085), the fillcount of 2
for namepool and fillcount of 4 for rdspool can fit 99.99% of request
for tested scenarios.
This was discovered by perf recording the single second recursive test
using flamethrower where the initial malloc lit up like a flare.
Current mempools are kind of hybrid structures - they serve two
purposes:
1. mempool with a lock is basically static sized allocator with
pre-allocated free items
2. mempool without a lock is a doubly-linked list of preallocated items
The first kind of usage could be easily replaced with jemalloc small
sized arena objects and thread-local caches.
The second usage not-so-much and we need to keep this (in
libdns:message.c) for performance reasons.
Every cppcheck update brings the cost of addressing new false positives
in the BIND 9 source code while not reaping any benefits in case of
identified issues with the code.
(cherry picked from commit 654cc61bb9)
The base image is in the process of being upgraded from Debian Buster to
Debian Bullseye, which has SoftHSM v2.6, the same SoftHSM version we
already test PKCS#11 with on Fedora. We don't need to test with two
SoftHSM 2.6 versions, drop CI jobs running on the base image.
This prevents a direct leak in OPENSSL_init_crypto (called from
OPENSSL_init_ssl).
Add shim version of OPENSSL_cleanup because it is missing in LibreSSL on
OpenBSD.
(cherry picked from commit 89f4f8f0c8)
On FreeBSD, the pthread primitives are not solely allocated on stack,
but part of the object lives on the heap. Missing pthread_*_destroy
causes the heap memory to grow and in case of fast lived object it's
possible to run out-of-memory.
Properly destroy the leaking mutex (worker->lock) and
the leaking condition (sock->cond).
(cherry picked from commit 57d0fabadd)
Previously, when TCP accept failed, we have logged a message with
ISC_LOG_ERROR level. One common case, how this could happen is that the
client hits TCP client quota and is put on hold and when resumed, the
client has already given up and closed the TCP connection. In such
case, the named would log:
TCP connection failed: socket is not connected
This message was quite confusing because it actually doesn't say that
it's related to the accepting the TCP connection and also it logs
everything on the ISC_LOG_ERROR level.
Change the log message to "Accepting TCP connection failed" and for
specific error states lower the severity of the log message to
ISC_LOG_INFO.
(cherry picked from commit 20ac73eb22)
Reconfigure the server without catalog-zone configuration, and then
put it back and reconfigure again, to confirm that there's no crash.
(cherry picked from commit bb411af31d)
The following scenario triggers a "named" crash:
1. Configure a catalog zone.
2. Start "named".
3. Comment out the "catalog-zone" clause.
4. Run `rndc reconfig`.
5. Uncomment the "catalog-zone" clause.
6. Run `rndc reconfig` again.
Implement the required cleanup of the in-memory catalog zone during
the first `rndc reconfig`, so that the second `rndc reconfig` could
find it in an expected state.
(cherry picked from commit 43ac2cd229)
