[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <F5184659D418E34EA12B1903EE5EF5FD8538E86653@seldmbx02.corpusers.net>
Date: Wed, 9 Oct 2013 00:40:00 +0200
From: "Bird, Tim" <Tim.Bird@...ymobile.com>
To: "Bird, Tim" <Tim.Bird@...ymobile.com>,
"cl@...ux.com" <cl@...ux.com>,
"catalin.marinas@....com" <catalin.marinas@....com>,
"Andersson, Björn"
<Bjorn.Andersson@...ymobile.com>,
"frowand.list@...il.com" <frowand.list@...il.com>,
"tbird20d@...il.com" <tbird20d@...il.com>
CC: "linux-mm@...ck.org" <linux-mm@...ck.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Bobniev, Roman" <Roman.Bobniev@...ymobile.com>
Subject: revert! RE: [PATCH] slub: proper kmemleak tracking if
CONFIG_SLUB_DEBUG disabled
Oh crud. Please ignore. I send the wrong patch. Real one coming very soon.
-- Tim
________________________________________
From: Tim Bird [tim.bird@...ymobile.com]
Sent: Tuesday, October 08, 2013 3:37 PM
To: cl@...ux.com; catalin.marinas@....com; Andersson, Björn; frowand.list@...il.com; Bird, Tim; tbird20d@...il.com
Cc: linux-mm@...ck.org; linux-kernel@...r.kernel.org; Bobniev, Roman
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