On Fri, 2022-10-21 at 16:07 -0700, Mike Kravetz wrote: > madvise(MADV_DONTNEED) ends up calling zap_page_range() to clear the > page tables associated with the address range. For hugetlb vmas, > zap_page_range will call __unmap_hugepage_range_final. However, > __unmap_hugepage_range_final assumes the passed vma is about to be > removed and deletes the vma_lock to prevent pmd sharing as the vma is > on the way out. In the case of madvise(MADV_DONTNEED) the vma > remains, > but the missing vma_lock prevents pmd sharing and could potentially > lead to issues with truncation/fault races. > > This issue was originally reported here [1] as a BUG triggered in > page_try_dup_anon_rmap. Prior to the introduction of the hugetlb > vma_lock, __unmap_hugepage_range_final cleared the VM_MAYSHARE flag > to > prevent pmd sharing. Subsequent faults on this vma were confused as > VM_MAYSHARE indicates a sharable vma, but was not set so page_mapping > was not set in new pages added to the page table. This resulted in > pages that appeared anonymous in a VM_SHARED vma and triggered the > BUG. > > Create a new routine clear_hugetlb_page_range() that can be called > from > madvise(MADV_DONTNEED) for hugetlb vmas. It has the same setup as > zap_page_range, but does not delete the vma_lock. > Reviewed-by: Rik van Riel <riel@xxxxxxxxxxx> -- All Rights Reversed.
Attachment:
signature.asc
Description: This is a digitally signed message part
