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