On 18 November 2015 at 09:26, Andrey Ryabinin <aryabi...@virtuozzo.com> wrote: > Kmemleak reports the following leak: > unreferenced object 0xfffffbfff41ea000 (size 20480): > comm "modprobe", pid 65199, jiffies 4298875551 (age 542.568s) > 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: > [<ffffffff82354f5e>] kmemleak_alloc+0x4e/0xc0 > [<ffffffff8152e718>] __vmalloc_node_range+0x4b8/0x740 > [<ffffffff81574072>] kasan_module_alloc+0x72/0xc0 > [<ffffffff810efe68>] module_alloc+0x78/0xb0 > [<ffffffff812f6a24>] module_alloc_update_bounds+0x14/0x70 > [<ffffffff812f8184>] layout_and_allocate+0x16f4/0x3c90 > [<ffffffff812faa1f>] load_module+0x2ff/0x6690 > [<ffffffff813010b6>] SyS_finit_module+0x136/0x170 > [<ffffffff8239bbc9>] system_call_fastpath+0x16/0x1b > [<ffffffffffffffff>] 0xffffffffffffffff > > kasan_module_alloc() allocates shadow memory for module and frees it on > module unloading. It doesn't store the pointer to allocated shadow memory > because it could be calculated from the shadowed address, i.e. > kasan_mem_to_shadow(addr). > Since kmemleak cannot find pointer to allocated shadow, it thinks that > memory leaked. > > Use kmemleak_ignore() to tell kmemleak that this is not a leak and shadow > memory doesn't contain any pointers. > > Signed-off-by: Andrey Ryabinin <aryabi...@virtuozzo.com> > Cc: Catalin Marinas <catalin.mari...@arm.com>
Acked-by: Catalin Marinas <catalin.mari...@arm.com> -- 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/
