hugetlb: allow faults to be handled under the VMA lock
authorVishal Moola (Oracle) <vishal.moola@gmail.com>
Wed, 21 Feb 2024 23:47:32 +0000 (15:47 -0800)
committerAndrew Morton <akpm@linux-foundation.org>
Tue, 5 Mar 2024 01:01:16 +0000 (17:01 -0800)
commit7c43a553792a1701affeef20959dfb2ccb26dcee
tree7d481e2a317a8cbcff1220929260b0a33a26f186
parent9acad7ba3e25d11f4c96df1b7312ae89e6faca5c
hugetlb: allow faults to be handled under the VMA lock

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.

Link: https://lkml.kernel.org/r/20240221234732.187629-6-vishal.moola@gmail.com
Signed-off-by: Vishal Moola (Oracle) <vishal.moola@gmail.com>
Reviewed-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Muchun Song <muchun.song@linux.dev>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
mm/hugetlb.c