It is generally safe to handle hugetlb faults under the VMA lock. The only time this is unsafe is when no anon_vma has been allocated to this vma yet, so we can use vmf_anon_prepare() instead of anon_vma_prepare() to bailout if necessary. This may only happen for the first non-shared hugetlb page in the vma. ----- The last patch in this series may cause ltp hugemmap10 to "fail". This is expected behavior - see the commit message for patch 3 in this series. The rest of the ltp hugetlb tests pass. This patchset applies cleanly ontop of mm-unstable. Vishal Moola (Oracle) (3): mm/memory: Change vmf_anon_prepare() to be non-static hugetlb: Use vmf_anon_prepare() instead of anon_vma_prepare() hugetlb: Allow faults to be handled under the VMA lock include/linux/hugetlb.h | 1 + mm/hugetlb.c | 33 +++++++++++++++++++++------------ mm/memory.c | 2 +- 3 files changed, 23 insertions(+), 13 deletions(-) -- 2.43.0
