summaryrefslogtreecommitdiffstats
path: root/src/vppinfra
diff options
context:
space:
mode:
authorAndrew Yourtchenko <ayourtch@gmail.com>2018-11-26 15:40:20 +0100
committerDave Barach <openvpp@barachs.net>2018-11-26 17:09:01 +0000
commit37f44563637d2fa2fe454fd8c100958ec9b7a754 (patch)
tree4173b7d133a0477efb583eb0e846e938f1ab816c /src/vppinfra
parent2af0e3a74c40e5df946813324574ccc18feb4761 (diff)
vppinfra: prevent dlmalloc from allocating memory via mmap_alloc()
If the heap does not have enough space to satisfy allocation request, the allocator calls sys_alloc(). There, if the request is bigger than mparams.mmap_threshold, the mmap_alloc() is called to allocate memory via a direct mmap call. The resulting allocated memory is properly recognized by clib_mem_is_heap_object() only for the first such request. Subsequent requests overwrite the tracking data, resulting in previously "valid" addresses become invalid, as seen by clib_mem_is_heap_object(). The result is a misleading behavior which masks other issues. This is a temporary change to avoid the affected codepath until there is a proper fix to track the directly mmap-allocated memory. Change-Id: I4137f91b5196d4503c40cf8ecc2f71554bc8f858 Signed-off-by: Andrew Yourtchenko <ayourtch@gmail.com>
Diffstat (limited to 'src/vppinfra')
-rw-r--r--src/vppinfra/dlmalloc.h23
1 files changed, 22 insertions, 1 deletions
diff --git a/src/vppinfra/dlmalloc.h b/src/vppinfra/dlmalloc.h
index e710b0c56ca..b7a8eea80a0 100644
--- a/src/vppinfra/dlmalloc.h
+++ b/src/vppinfra/dlmalloc.h
@@ -699,7 +699,28 @@ MAX_RELEASE_CHECK_RATE default: 4095 unless not HAVE_MMAP
#endif /* DEFAULT_TRIM_THRESHOLD */
#ifndef DEFAULT_MMAP_THRESHOLD
#if HAVE_MMAP
-#define DEFAULT_MMAP_THRESHOLD ((size_t)256U * (size_t)1024U)
+/*
+ * The default value in the dlmalloc was set as follows:
+ *
+ * #define DEFAULT_MMAP_THRESHOLD ((size_t)256U * (size_t)1024U)
+ *
+ * Above this threshold the sys_alloc() calls mmap_alloc() to directly mmap the memory.
+ * However, the interaction of this path with the rest of the vpp infra results
+ * in vpp infra considering directly mmap-allocated pieces to not
+ * be part of the heap, with predictable consequence.
+ *
+ * A simple unit-test to show that behavior is to make a small private
+ * heap and repeatedly perform vec_add1() within that heap.
+ *
+ * The issue is because there is no tracking which mmap-allocated chunk
+ * belongs to which heap.
+ *
+ * The temporary approach is to dial up the threshold so that the problematic
+ * code path never gets called. The full fix needs to introduce
+ * introduce the vector of mmap-allocated chunks to mspace, and in general
+ * do some more thorough testing.
+ */
+#define DEFAULT_MMAP_THRESHOLD ((size_t)~0ULL)
#else /* HAVE_MMAP */
#define DEFAULT_MMAP_THRESHOLD MAX_SIZE_T
#endif /* HAVE_MMAP */