kmemleak reported memory leak in kasan_module_alloc() like following
log, even through kasan_free_shadow() frees that address.
unreferenced object 0xfffffbfff40ac000 (size 118784):
comm "modprobe", pid 196, jiffies 4294878847 (age 87.590s)
hex dump (first 32 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<ffffffff81853a8e>] kmemleak_alloc+0x4e/0xc0
[<ffffffff812868d0>] __vmalloc_node_range+0x340/0x3f0
[<ffffffff812b0ae2>] kasan_module_alloc+0x72/0xd0
[<ffffffff8108c908>] module_alloc+0x78/0xb0
[<ffffffff81189474>] module_alloc_update_bounds+0x14/0x70
[<ffffffff8118a457>] load_module+0xf67/0x4670
[<ffffffff8118dd35>] SyS_init_module+0x1d5/0x220
[<ffffffff8186642e>] system_call_fastpath+0x12/0x71
[<ffffffffffffffff>] 0xffffffffffffffff
Kmemleak may think anyone take care of result of __vmalloc_node_range()
after the function.
So, it would be nice to call kmemleak_not_leak() to tell memory is not
leaked.
Signed-off-by: Masami Ichikawa <masami...@gmail.com>
---
mm/kasan/kasan.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/mm/kasan/kasan.c b/mm/kasan/kasan.c
index 6c513a6..0ef75b9 100644
--- a/mm/kasan/kasan.c
+++ b/mm/kasan/kasan.c
@@ -430,6 +430,7 @@ int kasan_module_alloc(void *addr, size_t size)
__builtin_return_address(0));
if (ret) {
+ kmemleak_not_leak(ret);
find_vm_area(addr)->flags |= VM_KASAN;
return 0;
}
--
2.4.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
