[0/3] hugetlb: fixes for new vma lock series

Message

Mike Kravetz Oct. 5, 2022, 1:17 a.m. UTC

In review of the series "hugetlb: Use new vma lock for huge pmd sharing
synchronization", Miaohe Lin pointed out two key issues:
1) There is a race in the routine hugetlb_unmap_file_folio when locks
   are dropped and reacquired in the correct order [1].
2) With the switch to using vma lock for fault/truncate synchronization,
   we need to make sure lock exists for all VM_MAYSHARE vmas, not just
   vmas capable of pmd sharing.

These two issues are addressed here.  In addition, having a vma lock
present in all VM_MAYSHARE vmas, uncovered some issues around vma
splitting.  Those are also addressed.

The series "hugetlb: Use new vma lock for huge pmd sharing synchronization"
is currently in mm-stable and may soon be merged???  This is why I am
sending 'fixes' to that series instead of a new version.  If a new
version of the series is preferred, I can do that.  Just wanted to get
these changes out for review.

[1] https://lore.kernel.org/linux-mm/[e-mail]/

Mike Kravetz (3):
  hugetlb: fix vma lock handling during split vma and range unmapping
  hugetlb: take hugetlb vma_lock when clearing vma_lock->vma pointer
  hugetlb: allocate vma lock for all sharable vmas

 mm/hugetlb.c | 127 +++++++++++++++++++++++++++------------------------
 mm/memory.c  |   4 --
 2 files changed, 68 insertions(+), 63 deletions(-)