Re: [PATCH] fork: fix kmemleak false positive due to thread stacks caching

[Catalin Marinas]

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