BIND merge requestshttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests2024-03-25T10:53:19Zhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8904[9.11] Work around a TSAN issue with newer kernels2024-03-25T10:53:19ZPetr Špačekpspacek@isc.org[9.11] Work around a TSAN issue with newer kernelsBackport of MR !8893
Closes #4649Backport of MR !8893
Closes #4649April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8895[9.16] Work around a TSAN issue with newer kernels2024-03-21T08:40:13ZPetr Špačekpspacek@isc.org[9.16] Work around a TSAN issue with newer kernelsBackport of MR !8893
Closes #4649Backport of MR !8893
Closes #4649April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8894[9.18] Work around a TSAN issue with newer kernels2024-03-21T08:40:01ZPetr Špačekpspacek@isc.org[9.18] Work around a TSAN issue with newer kernelsBackport of MR !8893
Closes #4649Backport of MR !8893
Closes #4649April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Petr Špačekpspacek@isc.orgPetr Špačekpspacek@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8893Work around a TSAN issue with newer kernels2024-03-22T08:31:26ZMichał KępieńWork around a TSAN issue with newer kernelsThe ThreadSanitizer version currently available from Fedora 39
repositories is unable to cope with very high ASLR entropy, which is the
default in some recent Linux distributions [1]. This causes all
TSAN-enabled builds to fail on the a...The ThreadSanitizer version currently available from Fedora 39
repositories is unable to cope with very high ASLR entropy, which is the
default in some recent Linux distributions [1]. This causes all
TSAN-enabled builds to fail on the affected systems with an error like:
FATAL: ThreadSanitizer: unexpected memory mapping 0x7d00e0772000-0x7d00e0c00000
Work around the problem by reducing ASLR entropy for all TSAN-enabled
builds until the problem is resolved upstream.
[1] https://github.com/google/sanitizers/issues/1716
Closes #4649April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8821Pin the xfr to a specific loop2024-03-08T11:26:09ZOndřej SurýPin the xfr to a specific loopInstead of getting the loop from the zone every time, attach the xfrin
directly to the loop. This also allows to remove the extra safety tid
checks from the dns_xfrin unit.
Closes #4600Instead of getting the loop from the zone every time, attach the xfrin
directly to the loop. This also allows to remove the extra safety tid
checks from the dns_xfrin unit.
Closes #4600March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8716prevent a possible race in setting up zone->xfr2024-03-08T08:34:27ZEvan Huntprevent a possible race in setting up zone->xfrthe call to dns_xfrin_create() wrote to zone->xfr with
the zone unlocked.the call to dns_xfrin_create() wrote to zone->xfr with
the zone unlocked.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8692Resolve "heap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddone"2024-02-08T17:34:48ZMark AndrewsResolve "heap-use-after-free lib/isccc/ccmsg.c:160 in ccmsg_senddone"Closes #4549Closes #4549March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8645Draft: Resolve "Data races in isc_buffer_peekuint8, rdataset_settrust, and me...2024-03-28T11:38:53ZMark AndrewsDraft: Resolve "Data races in isc_buffer_peekuint8, rdataset_settrust, and memmove"Lock access to the trust byte in lib/dns/ncache.c as they where causing TSAN errors.
Closes #4475Lock access to the trust byte in lib/dns/ncache.c as they where causing TSAN errors.
Closes #4475May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8586Resolve "Data races in isc_buffer_peekuint8, rdataset_settrust, and memmove"2024-03-06T09:07:53ZMatthijs Mekkingmatthijs@isc.orgResolve "Data races in isc_buffer_peekuint8, rdataset_settrust, and memmove"Enable the test that fails since it was revealed by !8515.
Closes #4475Enable the test that fails since it was revealed by !8515.
Closes #4475March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8579Resolve "ThreadSanitizer: data race xfrin.c:1555:2 in xfrin_send_request"2024-03-08T05:48:19ZArаm SаrgsyаnResolve "ThreadSanitizer: data race xfrin.c:1555:2 in xfrin_send_request"The atomic_init() function makes sense to use with structure's
members when creating a new instance of a strucutre. In other
places, use atomic store operations instead, in order to avoid
data races.
Closes #4493The atomic_init() function makes sense to use with structure's
members when creating a new instance of a strucutre. In other
places, use atomic store operations instead, in order to avoid
data races.
Closes #4493January 2024 (9.16.46, 9.16.46-S1, 9.18.22, 9.18.22-S1, 9.19.20) (❗RECALLED❗)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8550Draft: WIP: add more TID checks in validator2024-03-04T17:17:28ZOndřej SurýDraft: WIP: add more TID checks in validatorCloses #4475Closes #4475May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8474Use atomics for the the iterators number of isc_hashmap_t2023-12-06T18:18:20ZArаm SаrgsyаnUse atomics for the the iterators number of isc_hashmap_tThis is a follow-up MR from #4328.
Concurrent threads can access a hashmap for reading by creating and
then destroying an iterator, in which case the integer number of the
active iterators is increased or decreased from different thread...This is a follow-up MR from #4328.
Concurrent threads can access a hashmap for reading by creating and
then destroying an iterator, in which case the integer number of the
active iterators is increased or decreased from different threads,
introducing a data race. Use atomic operations to protect the variable.December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8473Resolve "ThreadSanitizer: data race in dns_tsigkeyring_dump"2023-12-06T18:18:29ZArаm SаrgsyаnResolve "ThreadSanitizer: data race in dns_tsigkeyring_dump"The 'dns_tsigkeyring_t' structure has a read/write lock to protect
its 'keys' member, which is a 'isc_hashmap_t' pointer and needs to
be protected.
The dns_tsigkeyring_dump() function, however, doesn't use the lock,
which can introduce ...The 'dns_tsigkeyring_t' structure has a read/write lock to protect
its 'keys' member, which is a 'isc_hashmap_t' pointer and needs to
be protected.
The dns_tsigkeyring_dump() function, however, doesn't use the lock,
which can introduce a race with another thread, if the other thread
tries to modify the hashmap.
Add a read lock around the code, which iterates over the hashmap.
Closes #4328December 2023 (9.18.21, 9.18.21-S1, 9.19.19)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8413[9.18] Resolve "Assertion failure in dns__catz_update_cb() on shutdown"2023-11-07T09:50:42ZArаm Sаrgsyаn[9.18] Resolve "Assertion failure in dns__catz_update_cb() on shutdown"Backport of !8409.
Closes #4381Backport of !8409.
Closes #4381November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8409Resolve "Assertion failure in dns__catz_update_cb() on shutdown"2023-11-07T09:50:41ZArаm SаrgsyаnResolve "Assertion failure in dns__catz_update_cb() on shutdown"The dns__catz_update_cb() does not expect that 'catzs->zones'
can become NULL during shutdown.
Add similar checks in the dns__catz_update_cb() and dns_catz_zone_get()
functions to protect from such a case. Also add an INSIST in the
dns_...The dns__catz_update_cb() does not expect that 'catzs->zones'
can become NULL during shutdown.
Add similar checks in the dns__catz_update_cb() and dns_catz_zone_get()
functions to protect from such a case. Also add an INSIST in the
dns_catz_zone_add() function to explicitly state that such a case
is not expected there, because that function is called only during a
reconfiguration.
Closes #4381November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8407Don't set the offloaded work result from main thread2023-11-07T09:57:40ZOndřej SurýDon't set the offloaded work result from main threadThe xfrin_recv_done() was accessing xfr->result where we stored the
result of the offloaded work from a thread that could receive data while
processing the transfer on the offloaded thread.
Completely remove the offloaded result from th...The xfrin_recv_done() was accessing xfr->result where we stored the
result of the offloaded work from a thread that could receive data while
processing the transfer on the offloaded thread.
Completely remove the offloaded result from the dns_xfrin_t structure
and keep it local for *xfr_apply() and *xfr_apply_done() as the failure
is already recorded in .shutdown_result and we now that the processing
has failed because .shuttingdown has been already set.
Closes #4380November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8333xfrin.c: use the statslock for more xfrin members2023-10-04T13:25:50ZArаm Sаrgsyаnxfrin.c: use the statslock for more xfrin membersThe 'end_serial' and some other members of the 'dns_xfrin_t'
structure can be accessed by the statistics channel, causing
a data race with the zone transfer process.
Use the existing 'statslock' mutex for protecting those members.
Clos...The 'end_serial' and some other members of the 'dns_xfrin_t'
structure can be accessed by the statistics channel, causing
a data race with the zone transfer process.
Use the existing 'statslock' mutex for protecting those members.
Closes #4332November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8315Replace mempool_{create,destroy} locking with RCU list2023-10-04T13:26:10ZOndřej SurýReplace mempool_{create,destroy} locking with RCU listAccording to the measurements, we spend quite a lot of time waiting for
the memory context lock in isc_mempool_{create,destroy}. Remove the
memory context lock, replace the mempool list with RCU list, and don't
protect the .checkfree an...According to the measurements, we spend quite a lot of time waiting for
the memory context lock in isc_mempool_{create,destroy}. Remove the
memory context lock, replace the mempool list with RCU list, and don't
protect the .checkfree and .name variables - those are constant for the
lifetime of the memory context anyway.
Closes #4325November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8203Attach to the dns_dispatchmgr in the dns_view object2023-08-31T15:15:07ZOndřej SurýAttach to the dns_dispatchmgr in the dns_view objectThe dns_dispatchmgr object was only set to the dns_view object making it
prone to use-after-free in the dns_xfrin unit when shutting down named.
Remove dns_view_setdispatchmgr() and optionally pass the dispatchmgr
directly to dns_view_c...The dns_dispatchmgr object was only set to the dns_view object making it
prone to use-after-free in the dns_xfrin unit when shutting down named.
Remove dns_view_setdispatchmgr() and optionally pass the dispatchmgr
directly to dns_view_create() when it is attached and not just assigned,
so the dns_dispatchmgr doesn't cease to exist too early.
The dns_view_getdnsdispatchmgr() is now protected by the RCU lock, the
dispatchmgr reference is incremented, so the caller needs to detach from
it, and the function can return NULL in case the dns_view has been
already shut down.
Closes #4228September 2023 (9.16.44, 9.16.44-S1, 9.18.19, 9.18.19-S1, 9.19.17)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8137Pin dns_request to the associated loop2023-07-28T12:38:53ZOndřej SurýPin dns_request to the associated loopWhen dns_request was canceled via dns_requestmgr_shutdown() the cancel
event would be propagated on different loop (loop 0) than the loop where
request was created on. In turn this would propagate down to isc_netmgr
where we require all...When dns_request was canceled via dns_requestmgr_shutdown() the cancel
event would be propagated on different loop (loop 0) than the loop where
request was created on. In turn this would propagate down to isc_netmgr
where we require all the events to be called from the matching isc_loop.
Pin the dns_requests to the loops and ensure that all the events are
called on the associated loop. This in turn allows us to remove the
hashed locks on the requests and change the single .requests list to be
a per-loop list for the request accounting.
Closes #4086August 2023 (9.16.43, 9.16.43-S1, 9.18.18, 9.18.18-S1, 9.19.16)Ondřej SurýOndřej Surý