On Wed, Feb 21, 2024 at 03:47:32PM -0800, Vishal Moola (Oracle) wrote: > Hugetlb can now safely handle faults under the VMA lock, so allow it to > do so. > > This patch may cause ltp hugemmap10 to "fail". Hugemmap10 tests hugetlb > counters, and expects the counters to remain unchanged on failure to > handle a fault. > > In hugetlb_no_page(), vmf_anon_prepare() may bailout with no anon_vma > under the VMA lock after allocating a folio for the hugepage. In > free_huge_folio(), this folio is completely freed on bailout iff there > is a surplus of hugetlb pages. This will remove a folio off the freelist > and decrement the number of hugepages while ltp expects these counters > to remain unchanged on failure. > > Originally this could only happen due to OOM failures, but now it may > also occur after we allocate a hugetlb folio without a suitable anon_vma > under the VMA lock. This should only happen for the first freshly > allocated hugepage in this vma. Hmm, so it's a bug in LTP. Have you talked to the LTP people about it (cc's added)? Also, did you try moving the anon_vma check befor the folio allocation so that you can bail out without disturbing the counters? > Signed-off-by: Vishal Moola (Oracle) <vishal.moola@xxxxxxxxx> Reviewed-by: Matthew Wilcox (Oracle) <willy@xxxxxxxxxxxxx>
