| Message ID | 20221111232628.290160-3-mike.kravetz@oracle.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | fix hugetlb MADV_DONTNEED vma_lock handling | expand |
On 12.11.22 00:26, Mike Kravetz wrote: > The common hugetlb unmap routine __unmap_hugepage_range performs mmu > notification calls. However, in the case where __unmap_hugepage_range > is called via __unmap_hugepage_range_final, mmu notification calls are > performed earlier in other calling routines. > > Remove mmu notification calls from __unmap_hugepage_range. Add > notification calls to the only other caller: unmap_hugepage_range. > unmap_hugepage_range is called for truncation and hole punch, so > change notification type from UNMAP to CLEAR as this is more appropriate. > > Fixes: 90e7e7f5ef3f ("mm: enable MADV_DONTNEED for hugetlb mappings") > Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> > Reported-by: Wei Chen <harperchen1110@gmail.com> > Cc: <stable@vger.kernel.org> Why exactly do we care about stable backports here? What's the user-visible impact?
On 11/14/22 10:06, David Hildenbrand wrote: > On 12.11.22 00:26, Mike Kravetz wrote: > > The common hugetlb unmap routine __unmap_hugepage_range performs mmu > > notification calls. However, in the case where __unmap_hugepage_range > > is called via __unmap_hugepage_range_final, mmu notification calls are > > performed earlier in other calling routines. > > > > Remove mmu notification calls from __unmap_hugepage_range. Add > > notification calls to the only other caller: unmap_hugepage_range. > > unmap_hugepage_range is called for truncation and hole punch, so > > change notification type from UNMAP to CLEAR as this is more appropriate. > > > > Fixes: 90e7e7f5ef3f ("mm: enable MADV_DONTNEED for hugetlb mappings") > > Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> > > Reported-by: Wei Chen <harperchen1110@gmail.com> > > Cc: <stable@vger.kernel.org> > > Why exactly do we care about stable backports here? What's the user-visible > impact? I do not believe the duplicate notification calls have a user-visible impact. They have existed for a long time without notice. When fixing this issue, this was noticed and cleaned up. We should be able to fix the issue without this change. Unless someone really thinks this needs to be fixed in stable as well. I will move this to the end of the patch series and drop the Fixes/Cc stable tags. Will send out later today as I will want to do another round of testing.
diff --git a/mm/hugetlb.c b/mm/hugetlb.c index 9d765364231e..205c67c6787a 100644 --- a/mm/hugetlb.c +++ b/mm/hugetlb.c @@ -5074,7 +5074,6 @@ static void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct struct page *page; struct hstate *h = hstate_vma(vma); unsigned long sz = huge_page_size(h); - struct mmu_notifier_range range; unsigned long last_addr_mask; bool force_flush = false; @@ -5089,13 +5088,6 @@ static void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct tlb_change_page_size(tlb, sz); tlb_start_vma(tlb, vma); - /* - * If sharing possible, alert mmu notifiers of worst case. - */ - mmu_notifier_range_init(&range, MMU_NOTIFY_UNMAP, 0, vma, mm, start, - end); - adjust_range_if_pmd_sharing_possible(vma, &range.start, &range.end); - mmu_notifier_invalidate_range_start(&range); last_addr_mask = hugetlb_mask_last_page(h); address = start; for (; address < end; address += sz) { @@ -5180,7 +5172,6 @@ static void __unmap_hugepage_range(struct mmu_gather *tlb, struct vm_area_struct if (ref_page) break; } - mmu_notifier_invalidate_range_end(&range); tlb_end_vma(tlb, vma); /* @@ -5208,6 +5199,7 @@ void __unmap_hugepage_range_final(struct mmu_gather *tlb, hugetlb_vma_lock_write(vma); i_mmap_lock_write(vma->vm_file->f_mapping); + /* mmu notification performed in caller */ __unmap_hugepage_range(tlb, vma, start, end, ref_page, zap_flags); /* @@ -5227,10 +5219,18 @@ void unmap_hugepage_range(struct vm_area_struct *vma, unsigned long start, unsigned long end, struct page *ref_page, zap_flags_t zap_flags) { + struct mmu_notifier_range range; struct mmu_gather tlb; + mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma, vma->vm_mm, + start, end); + adjust_range_if_pmd_sharing_possible(vma, &range.start, &range.end); + mmu_notifier_invalidate_range_start(&range); tlb_gather_mmu(&tlb, vma->vm_mm); + __unmap_hugepage_range(&tlb, vma, start, end, ref_page, zap_flags); + + mmu_notifier_invalidate_range_end(&range); tlb_finish_mmu(&tlb); }
The common hugetlb unmap routine __unmap_hugepage_range performs mmu notification calls. However, in the case where __unmap_hugepage_range is called via __unmap_hugepage_range_final, mmu notification calls are performed earlier in other calling routines. Remove mmu notification calls from __unmap_hugepage_range. Add notification calls to the only other caller: unmap_hugepage_range. unmap_hugepage_range is called for truncation and hole punch, so change notification type from UNMAP to CLEAR as this is more appropriate. Fixes: 90e7e7f5ef3f ("mm: enable MADV_DONTNEED for hugetlb mappings") Signed-off-by: Mike Kravetz <mike.kravetz@oracle.com> Reported-by: Wei Chen <harperchen1110@gmail.com> Cc: <stable@vger.kernel.org> --- mm/hugetlb.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)