diff mbox

malloc: plug thread-cache memory leak

Message ID 1453767942-19369-53-git-send-email-joern@purestorage.com
State New
Headers show

Commit Message

Jörn Engel Jan. 26, 2016, 12:25 a.m. UTC
Freeing the cache into itself is an exploit worthy of Münchhausen.  We
only leaked a little memory and only when destroying threads.  But low
impact is no excuse for silly bugs.

JIRA: PURE-27597
---
 tpc/malloc2.13/tcache.h | 10 ++++++++++
 1 file changed, 10 insertions(+)
diff mbox

Patch

diff --git a/tpc/malloc2.13/tcache.h b/tpc/malloc2.13/tcache.h
index ece03fc464cd..b7bdb9ad41e4 100644
--- a/tpc/malloc2.13/tcache.h
+++ b/tpc/malloc2.13/tcache.h
@@ -226,6 +226,7 @@  static void tcache_destroy(void *_cache)
 {
 	struct thread_cache *cache = _cache;
 
+	mutex_lock(&cache->mutex);
 	/*
 	 * tcache_gc almost does what we want.  It tries hard to only
 	 * free part of the cache, but call it often enough and it
@@ -234,6 +235,15 @@  static void tcache_destroy(void *_cache)
 	 */
 	while (cache->tc_count)
 		tcache_gc(cache);
+	/*
+	 * public_free will call tcache_free, which could free the
+	 * cache into... the cache.  Result would be a memory leak.
+	 * But since we hold the cache-mutex, it cannot and has to
+	 * free the memory back to the arena.
+	 * A bit of a hack, but creates smaller code than having a
+	 * second copy of uncached_free.  And this is by no means a
+	 * performance-critical path.
+	 */
 	public_fREe(cache);
 }