lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <1381271832-13047-1-git-send-email-tim.bird@sonymobile.com>
Date:	Tue, 8 Oct 2013 15:37:12 -0700
From:	Tim Bird <tim.bird@...ymobile.com>
To:	<cl@...ux.com>, <catalin.marinas@....com>,
	<bjorn.andersson@...ymobile.com>, <frowand.list@...il.com>,
	<tim.bird@...ymobile.com>, <tbird20d@...il.com>
CC:	<linux-mm@...ck.org>, <linux-kernel@...r.kernel.org>,
	Roman Bobniev <Roman.Bobniev@...ymobile.com>
Subject: [PATCH] slub: proper kmemleak tracking if CONFIG_SLUB_DEBUG disabled

From: Roman Bobniev <Roman.Bobniev@...ymobile.com>

Move more kmemleak calls into hook functions, and make it so
that all hooks (both inside and outside of #ifdef CONFIG_SLUB_DEBUG_ON)
call the appropriate kmemleak routines.  This allows for
kmemleak to be configured independently of slub debug features.

It also fixes a bug where kmemleak was only partially enabled
in some configurations.

Signed-off-by: Roman Bobniev <Roman.Bobniev@...ymobile.com>
Signed-off-by: Tim Bird <tim.bird@...ymobile.com>
---
 mm/slub.c | 40 ++++++++++++++++++++++++++++++++++++----
 1 file changed, 36 insertions(+), 4 deletions(-)

diff --git a/mm/slub.c b/mm/slub.c
index c3eb3d3..95e170e 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -933,6 +933,11 @@ static void trace(struct kmem_cache *s, struct page *page, void *object,
  * Hooks for other subsystems that check memory allocations. In a typical
  * production configuration these hooks all should produce no code at all.
  */
+static inline post_alloc_hook(void *ptr, size_t size, gfp_t flags)
+{
+	kmemleak_alloc(ptr, size, 1, flags);
+}
+
 static inline int slab_pre_alloc_hook(struct kmem_cache *s, gfp_t flags)
 {
 	flags &= gfp_allowed_mask;
@@ -973,6 +978,11 @@ static inline void slab_free_hook(struct kmem_cache *s, void *x)
 		debug_check_no_obj_freed(x, s->object_size);
 }
 
+static inline void free_hook(void *x)
+{
+	kmemleak_free(x);
+}
+
 /*
  * Tracking of fully allocated slabs for debugging purposes.
  *
@@ -1260,13 +1270,35 @@ static inline void inc_slabs_node(struct kmem_cache *s, int node,
 static inline void dec_slabs_node(struct kmem_cache *s, int node,
 							int objects) {}
 
+/*
+ * Define the hook functions as empty of most debug code.
+ * However, leave the kmemleak calls so they can be configured
+ * independently of CONFIG_SLUB_DEBUG_ON.
+ */
+static inline post_alloc_hook(void *ptr, size_t size, gfp_t flags)
+{
+	kmemleak_alloc(ptr, size, 1, flags);
+}
+
 static inline int slab_pre_alloc_hook(struct kmem_cache *s, gfp_t flags)
 							{ return 0; }
 
 static inline void slab_post_alloc_hook(struct kmem_cache *s, gfp_t flags,
-		void *object) {}
+		void *object)
+{
+	kmemleak_alloc_recursive(object, s->object_size, 1, s->flags,
+		flags & gfp_allowed_mask);
+}
 
-static inline void slab_free_hook(struct kmem_cache *s, void *x) {}
+static inline void slab_free_hook(struct kmem_cache *s, void *x)
+{
+	kmemleak_free_recursive(x, s->flags);
+}
+
+static inline void free_hook(void *x)
+{
+	kmemleak_free(x);
+}
 
 #endif /* CONFIG_SLUB_DEBUG */
 
@@ -3272,7 +3304,7 @@ static void *kmalloc_large_node(size_t size, gfp_t flags, int node)
 	if (page)
 		ptr = page_address(page);
 
-	kmemleak_alloc(ptr, size, 1, flags);
+	post_alloc_hook(ptr, size, flags);
 	return ptr;
 }
 
@@ -3336,7 +3368,7 @@ void kfree(const void *x)
 	page = virt_to_head_page(x);
 	if (unlikely(!PageSlab(page))) {
 		BUG_ON(!PageCompound(page));
-		kmemleak_free(x);
+		free_hook(x);
 		__free_memcg_kmem_pages(page, compound_order(page));
 		return;
 	}
-- 
1.8.2.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ