lkml.org 
[lkml]   [2022]   [Oct]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Observed memory leak in hugetlb_reserve_pages
On 10/17/22 13:11, Lukas Bulwahn wrote:
> Dear Mike,
>
> The reproducer for the 'memory leak in hugetlb_reserve_pages' bug (see
> https://elisa-builder-00.iol.unh.edu/syzkaller-next/report?id=3469603f4a0da86b581cc979bd6c6663b46ceb1b)
> is reproducible, it is triggering the memory leak on the current
> mainline (commit 60bb8154d1d7), and it was not triggering on v6.0. My
> build config is a x86_64 defconfig with some syzkaller-recommended
> debug options.

Thank you Lukas!

The leak is embarrassingly obvious. Here is a bit of code at the beginning of
hugetlb_reserve_pages:

/*
* vma specific semaphore used for pmd sharing synchronization
*/
hugetlb_vma_lock_alloc(vma);

/*
* Only apply hugepage reservation if asked. At fault time, an
* attempt will be made for VM_NORESERVE to allocate a page
* without using reserves
*/
if (vm_flags & VM_NORESERVE)
return true;

There needs to be a hugetlb_vma_lock_free(vma) call before that return.

I will do some testing and send a patch. However, I will use commit
8d9bfb2608145 in the Fixes: tag. This is because that commit added the
call to hugetlb_vma_lock_alloc in hugetlb_reserve_pages without the
hugetlb_vma_lock_free in the VM_NORESERVE return.

> My git bisection showed that the first bad commit is
> [bbff39cc6cbcb86ccfacb2dcafc79912a9f9df69] hugetlb: allocate vma lock
> for all sharable vmas.

The reason your bisect pointed to bbff39cc6cbc is because the mmap/vma size in
the test case is not sufficient for pmd sharing. Therefore, the test did not
experience a leak until the patch which allocates the vma lock for ALL vmas
was added.
--
Mike Kravetz

\
 
 \ /
  Last update: 2022-10-17 19:39    [W:0.042 / U:0.348 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site