[PATCH v2] kmemleak: survive in a low-memory situation

From: Qian Cai
Date: Wed Jan 02 2019 - 13:07:08 EST

Kmemleak could quickly fail to allocate an object structure and then
disable itself in a low-memory situation. For example, running a mmap()
workload triggering swapping and OOM [1].

Kmemleak allocation could fail even though the trackig object is
succeeded. Hence, it could still try to start a direct reclaim if it is
not executed in an atomic context (spinlock, irq-handler etc), or a
high-priority allocation in an atomic context as a last-ditch effort.


Signed-off-by: Qian Cai <cai@xxxxxx>

v2: remove the needless checking for NULL objects in slab_post_alloc_hook()
pointed out by Catalin.

mm/kmemleak.c | 10 ++++++++++
1 file changed, 10 insertions(+)

diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index f9d9dc250428..9e1aa3b7df75 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -576,6 +576,16 @@ static struct kmemleak_object *create_object(unsigned long ptr, size_t size,
struct rb_node **link, *rb_parent;

object = kmem_cache_alloc(object_cache, gfp_kmemleak_mask(gfp));
+ if (!object) {
+ /* last-ditch effort in a low-memory situation */
+ if (irqs_disabled() || is_idle_task(current) || in_atomic())
+ gfp = GFP_ATOMIC;
+ else
+ gfp = gfp_kmemleak_mask(gfp) | __GFP_DIRECT_RECLAIM;
+ object = kmem_cache_alloc(object_cache, gfp);
+ }
if (!object) {
pr_warn("Cannot allocate a kmemleak_object structure\n");
2.17.2 (Apple Git-113)