On Fri, May 26, 2017 at 02:49:49PM +0100, Luis Henriques wrote:
> kmemleak has been reporting memory leaks since commit ac496bf48d97 ("fork:
> Optimize task creation by caching two thread stacks per CPU if
> CONFIG_VMAP_STACK=y"):
>
> unreferenced object 0xffffc900002b0000 (size 16384):
> comm "init", pid 147, jiffies 4294893306 (age 11.292s)
> hex dump (first 32 bytes):
> 9d 6e ac 57 00 00 00 00 00 00 00 00 00 00 00 00 .n.W............
> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
> backtrace:
> [<ffffffff815b481e>] kmemleak_alloc+0x4e/0xb0
> [<ffffffff8112a8b0>] __vmalloc_node_range+0x160/0x240
> [<ffffffff8104a328>] copy_process.part.8+0x478/0x1630
> [<ffffffff8104b69a>] _do_fork+0xca/0x330
> [<ffffffff8104b9a9>] SyS_clone+0x19/0x20
> [<ffffffff8100199c>] do_syscall_64+0x4c/0xb0
> [<ffffffff815b8d06>] return_from_SYSCALL_64+0x0/0x6a
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> This is because this commit started caching 2 thread stacks per CPU, and
> kmemleak assumes its memory is never freed. Report these stacks as not
> being memory leaks using kmemleak_not_leak().
>
> Cc: stable@xxxxxxxxxxxxxxx
> Fixes: ac496bf48d97 ("fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y")
> Signed-off-by: Luis Henriques <lhenriques@xxxxxxxx>
I guess that's meant as a 4.12 and earlier fix until the
kmemleak_vmalloc() patches go in
(http://lkml.kernel.org/r/1495726937-23557-1-git-send-email-catalin.marinas@xxxxxxx)
> diff --git a/kernel/fork.c b/kernel/fork.c
> index aa1076c5e4a9..c4d79ad0f5bc 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -255,6 +255,7 @@ static inline void free_thread_stack(struct task_struct *tsk)
>
> this_cpu_write(cached_stacks[i], tsk->stack_vm_area);
> local_irq_restore(flags);
> + kmemleak_not_leak(tsk->stack);
I would add a comment here on why the annotation is needed.
The disadvantage is that such objects would no longer be detected as
leaks since kmemleak doesn't have a way to "unignore" an object (I have
a patch but not worth merging since we'll fix the above with a dedicated
kmemleak_vmalloc() API). We could however work around this with the
current kmemleak API as in this patch:
http://lkml.kernel.org/r/20170516133925.GA9453@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks.
--
Catalin