debugobjects: Make kmemleak ignore debug objects
Subsystems (2)
PATCH 1/1 debugobjects: Make kmemleak ignore debug objects
The allocated debug objects are either on the free list or in the hashed bucket lists. So they won't get lost. However if both debug objects and kmemleak are enabled and kmemleak scanning is done while some of the debug objects are transitioning from one list to the others, false negative reporting of memory leaks may happen for those objects. For example,
[38687.275678] kmemleak: 12 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
unreferenced object 0xffff92e98aabeb68 (size 40):
comm "ksmtuned", pid 4344, jiffies 4298403600 (age 906.430s) hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 d0 bc db 92 e9 92 ff ff ................
01 00 00 00 00 00 00 00 38 36 8a 61 e9 92 ff ff ........86.a....
backtrace:
[<ffffffff8fa5378a>] kmemleak_alloc+0x4a/0xa0
[<ffffffff8f47c019>] kmem_cache_alloc+0xe9/0x320
[<ffffffff8f62ed96>] __debug_object_init+0x3e6/0x400
[<ffffffff8f62ef01>] debug_object_activate+0x131/0x210
[<ffffffff8f330d9f>] __call_rcu+0x3f/0x400
[<ffffffff8f33117d>] call_rcu_sched+0x1d/0x20
[<ffffffff8f4a183c>] put_object+0x2c/0x40
[<ffffffff8f4a188c>] __delete_object+0x3c/0x50
[<ffffffff8f4a18bd>] delete_object_full+0x1d/0x20
[<ffffffff8fa535c2>] kmemleak_free+0x32/0x80
[<ffffffff8f47af07>] kmem_cache_free+0x77/0x350
[<ffffffff8f453912>] unlink_anon_vmas+0x82/0x1e0
[<ffffffff8f440341>] free_pgtables+0xa1/0x110
[<ffffffff8f44af91>] exit_mmap+0xc1/0x170
[<ffffffff8f29db60>] mmput+0x80/0x150
[<ffffffff8f2a7609>] do_exit+0x2a9/0xd20The references in the debug objects may also hide a real memory leak.
As there is no point in having kmemleak to track debug object allocations, kmemleak checking is now disabled for debug objects.
--- init/main.c | 2 +- lib/debugobjects.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
init/main.c +1 -1
@@ -660,8 +660,8 @@ asmlinkage __visible void __init start_kernel(void) }#endif page_ext_init (); -debug_objects_mem_init ();kmemleak_init (); +debug_objects_mem_init ();setup_per_cpu_pageset ();numa_policy_init ();if (late_time_init)
lib/debugobjects.c +3 -0
@@ -18,6 +18,7 @@#include <linux/debugfs.h> #include <linux/slab.h> #include <linux/hash.h> +#include <linux/kmemleak.h> #define ODEBUG_HASH_BITS 14#define ODEBUG_HASH_SIZE (1 << ODEBUG_HASH_BITS)
@@ -110,6 +111,7 @@ static void fill_pool(void)if (!new)return ; +kmemleak_ignore (new);raw_spin_lock_irqsave (&pool_lock, flags);hlist_add_head (&new->node, &obj_pool); debug_objects_allocated++;
@@ -1080,6 +1082,7 @@ static int __init debug_objects_replace_static_objects(void) obj =kmem_cache_zalloc (obj_cache,GFP_KERNEL );if (!obj) goto free; +kmemleak_ignore (obj);hlist_add_head (&obj->node, &objects); }
Signature · 1 line
1.8.3.1
tip-bot for Waiman Long
merge botdebugobjects: Make kmemleak ignore debug objects
Commit-ID: caba4cbbd27d755572730801ac34fe063fc40a32 Gitweb: http://git.kernel.org/tip/caba4cbbd27d755572730801ac34fe063fc40a32 Author: Waiman Long <[email protected]> AuthorDate: Mon, 14 Aug 2017 09:52:13 -0400 Committer: Thomas Gleixner <[email protected]> CommitDate: Mon, 14 Aug 2017 16:51:01 +0200
debugobjects: Make kmemleak ignore debug objects
The allocated debug objects are either on the free list or in the hashed bucket lists. So they won't get lost. However if both debug objects and kmemleak are enabled and kmemleak scanning is done while some of the debug objects are transitioning from one list to the others, false negative reporting of memory leaks may happen for those objects. For example,
[38687.275678] kmemleak: 12 new suspected memory leaks (see
/sys/kernel/debug/kmemleak)
unreferenced object 0xffff92e98aabeb68 (size 40):
comm "ksmtuned", pid 4344, jiffies 4298403600 (age 906.430s) hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 d0 bc db 92 e9 92 ff ff ................
01 00 00 00 00 00 00 00 38 36 8a 61 e9 92 ff ff ........86.a....
backtrace:
[<ffffffff8fa5378a>] kmemleak_alloc+0x4a/0xa0
[<ffffffff8f47c019>] kmem_cache_alloc+0xe9/0x320
[<ffffffff8f62ed96>] __debug_object_init+0x3e6/0x400
[<ffffffff8f62ef01>] debug_object_activate+0x131/0x210
[<ffffffff8f330d9f>] __call_rcu+0x3f/0x400
[<ffffffff8f33117d>] call_rcu_sched+0x1d/0x20
[<ffffffff8f4a183c>] put_object+0x2c/0x40
[<ffffffff8f4a188c>] __delete_object+0x3c/0x50
[<ffffffff8f4a18bd>] delete_object_full+0x1d/0x20
[<ffffffff8fa535c2>] kmemleak_free+0x32/0x80
[<ffffffff8f47af07>] kmem_cache_free+0x77/0x350
[<ffffffff8f453912>] unlink_anon_vmas+0x82/0x1e0
[<ffffffff8f440341>] free_pgtables+0xa1/0x110
[<ffffffff8f44af91>] exit_mmap+0xc1/0x170
[<ffffffff8f29db60>] mmput+0x80/0x150
[<ffffffff8f2a7609>] do_exit+0x2a9/0xd20The references in the debug objects may also hide a real memory leak.
As there is no point in having kmemleak to track debug object allocations, kmemleak checking is now disabled for debug objects.
--- init/main.c | 2 +- lib/debugobjects.c | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-)
init/main.c +1 -1
@@ -651,8 +651,8 @@ asmlinkage __visible void __init start_kernel(void) }#endif page_ext_init (); -debug_objects_mem_init ();kmemleak_init (); +debug_objects_mem_init ();setup_per_cpu_pageset ();numa_policy_init ();if (late_time_init)
lib/debugobjects.c +3 -0
@@ -18,6 +18,7 @@#include <linux/debugfs.h> #include <linux/slab.h> #include <linux/hash.h> +#include <linux/kmemleak.h> #define ODEBUG_HASH_BITS 14#define ODEBUG_HASH_SIZE (1 << ODEBUG_HASH_BITS)
@@ -110,6 +111,7 @@ static void fill_pool(void)if (!new)return ; +kmemleak_ignore (new);raw_spin_lock_irqsave (&pool_lock, flags);hlist_add_head (&new->node, &obj_pool); debug_objects_allocated++;
@@ -1080,6 +1082,7 @@ static int __init debug_objects_replace_static_objects(void) obj =kmem_cache_zalloc (obj_cache,GFP_KERNEL );if (!obj) goto free; +kmemleak_ignore (obj);hlist_add_head (&obj->node, &objects); }