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/01f10195-7088-4462-6def-909549c75ef4@xxxxxxxxxx/ 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(-) -- 2.37.3
