ComputerSurge/bind9
3
0
Fork 0
Code Pull Requests 1 Activity

Call rcu_barrier() five times in the isc__mem_destroy()

Browse Source 
Because rcu_barrier() needs to be called as many times as the number of
nested call_rcu() calls (call_rcu() calls made from call_rcu thread),
and currently there's no mechanism to detect whether there are more
call_rcu callbacks scheduled, we simply call the rcu_barrier() multiple
times.  The overhead is negligible and it prevents rare assertion
failures caused by the check for memory leaks in isc__mem_destroy().
This commit is contained in:
Ondřej Surý
2023-06-27 08:26:12 +02:00
parent 1e3b6d2d83
commit c1821ccf92
1 changed files with 17 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

18
lib/isc/mem.c
View File

@@ -582,9 +582,25 @@ isc__mem_destroy(isc_mem_t **ctxp FLARG) {
/*
* wait for asynchronous memory reclamation to complete
* before checking for memory leaks
* before checking for memory leaks.
*
* Because rcu_barrier() needs to be called as many times
* as the number of nested call_rcu() calls (call_rcu()
* calls made from call_rcu thread), and currently there's
* no mechanism to detect whether there are more call_rcu
* callbacks scheduled, we simply call the rcu_barrier()
* multiple times. The overhead is negligible and it
* prevents rare assertion failures caused by the check
* for memory leaks below.
*
* If there's more nested call_rcu() calls than five levels,
* we are doing something horribly wrong...
*/
rcu_barrier();
rcu_barrier();
rcu_barrier();
rcu_barrier();
rcu_barrier();
#if ISC_MEM_TRACKLINES
if ((ctx->debugging & ISC_MEM_DEBUGTRACE) != 0) {