On 10/17/22 10:38, Mike Kravetz wrote: > 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. Please ignore this email. I sent it before looking (or thinking) closely. -- Mike Kravetz
