* Qian Cai <quic_qiancai@quicinc.com> [220427 16:22]:
> On Wed, Apr 27, 2022 at 04:51:50PM +0000, Liam Howlett wrote:
> > Thanks.  This is indeed an issue with 0d43186b36c1 (mm/mlock: use vma
> > iterator and instead of vma linked list)                                                 
> > 
> > Andrew, Please include this patch as a fix.
> 
> Even with the patch applied, there are still thousands of memory leaks
> reports from kmemleak after booting.

Thank you for finding this.

> 
> unreferenced object 0xffff400259bd6d00 (size 256):
>   comm "multipathd", pid 2577, jiffies 4294915929 (age 2370.384s)
>   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:
>      slab_post_alloc_hook
>      kmem_cache_alloc_bulk
>      mas_alloc_nodes
>      mt_alloc_bulk at lib/maple_tree.c:151
>      (inlined by) mas_alloc_nodes at lib/maple_tree.c:1244
>      mas_preallocate
>      __vma_adjust
>      shift_arg_pages
>      setup_arg_pages
>      load_elf_binary
>      search_binary_handler
>      exec_binprm
>      bprm_execve
>      do_execveat_common.isra.0
>      __arm64_sys_execve
>      invoke_syscall
>      el0_svc_common.constprop.0
>      do_el0_svc

__vma_adjust is way too complicated.  This patch should fix the leak.

Andrew, please add this patch to "mm: start tracking VMAs with maple tree"


Thanks,
Liam