BUG/MINOR: pools: fix a possible memory leak in the lockless pool_flush()
The lockless version of pool_flush() had a leftover of the original
version causing the pool's first entry to be set to NULL at the end.
The problem is that it does this outside of any lock and in a non-
atomic way, so that any concurrent alloc+free would result in a lost
object.
The risk is low and the consequence even lower, given that pool_flush()
is only used in pool_destroy() (hence single-threaded) or by stream_free()
during a soft-stop (not the place where most allocations happen), so in
the worst case it could result in valgrind complaining on soft-stop.
The bug was introduced with the first version of the code, in 1.9, so
the fix can be backported to all stable versions.
(cherry picked from commit c239cde26fbf0b07abdf590b77c31154bd65c566)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit caf6555f418767a1298aa7e273609fc1510184db)
[wt: adjusted context: pool->allocated still updated last]
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit d5c271756d8cd9b6234dfbb6a1d1e09f5b8e89e0)
Signed-off-by: Willy Tarreau <w@1wt.eu>
(cherry picked from commit 30174f5b97f8043652a98a9445ccc9269df6fc12)
Signed-off-by: Willy Tarreau <w@1wt.eu>
diff --git a/src/memory.c b/src/memory.c
index 126d534..cc0dac7 100644
--- a/src/memory.c
+++ b/src/memory.c
@@ -245,9 +245,8 @@
removed++;
free(temp);
}
- pool->free_list = next;
_HA_ATOMIC_SUB(&pool->allocated, removed);
- /* here, we should have pool->allocate == pool->used */
+ /* here, we should have pool->allocated == pool->used */
}
/*