mm: follow_pte() improvements

jira LE-3557
Rebuild_History Non-Buildable kernel-5.14.0-570.26.1.el9_6
commit-author David Hildenbrand <[email protected]>
commit c5541ba
Empty-Commit: Cherry-Pick Conflicts during history rebuild.
Will be included in final tarball splat. Ref for failed cherry-pick at:
ciq/ciq_backports/kernel-5.14.0-570.26.1.el9_6/c5541ba3.failed

follow_pte() is now our main function to lookup PTEs in VM_PFNMAP/VM_IO
VMAs.  Let's perform some more sanity checks to make this exported
function harder to abuse.

Further, extend the doc a bit, it still focuses on the KVM use case with
MMU notifiers.  Drop the KVM+follow_pfn() comment, follow_pfn() is no
more, and we have other users nowadays.

Also extend the doc regarding refcounted pages and the interaction with
MMU notifiers.

KVM is one example that uses MMU notifiers and can deal with refcounted
pages properly.  VFIO is one example that doesn't use MMU notifiers, and
to prevent use-after-free, rejects refcounted pages: pfn_valid(pfn) &&
!PageReserved(pfn_to_page(pfn)).  Protection changes are less of a concern
for users like VFIO: the behavior is similar to longterm-pinning a page,
and getting the PTE protection changed afterwards.

The primary concern with refcounted pages is use-after-free, which callers
should be aware of.

Link: https://lkml.kernel.org/r/[email protected]
	Signed-off-by: David Hildenbrand <[email protected]>
	Cc: Alex Williamson <[email protected]>
	Cc: Christoph Hellwig <[email protected]>
	Cc: Fei Li <[email protected]>
	Cc: Gerald Schaefer <[email protected]>
	Cc: Heiko Carstens <[email protected]>
	Cc: Ingo Molnar <[email protected]>
	Cc: Paolo Bonzini <[email protected]>
	Cc: Sean Christopherson <[email protected]>
	Cc: Yonghua Huang <[email protected]>
	Signed-off-by: Andrew Morton <[email protected]>
(cherry picked from commit c5541ba)
	Signed-off-by: Jonathan Maple <[email protected]>

# Conflicts:
#	mm/memory.c

Author: PlaidCat

ciq/ciq_backports/kernel-5.14.0-570.26.1.el9_6/c5541ba3.failed

@@ -0,0 +1,83 @@
+mm: follow_pte() improvements
+
+jira LE-3557
+Rebuild_History Non-Buildable kernel-5.14.0-570.26.1.el9_6
+commit-author David Hildenbrand <[email protected]>
+commit c5541ba378e3d36ea88bf5839d5b23e33e7d1627
+Empty-Commit: Cherry-Pick Conflicts during history rebuild.
+Will be included in final tarball splat. Ref for failed cherry-pick at:
+ciq/ciq_backports/kernel-5.14.0-570.26.1.el9_6/c5541ba3.failed
+
+follow_pte() is now our main function to lookup PTEs in VM_PFNMAP/VM_IO
+VMAs.  Let's perform some more sanity checks to make this exported
+function harder to abuse.
+
+Further, extend the doc a bit, it still focuses on the KVM use case with
+MMU notifiers.  Drop the KVM+follow_pfn() comment, follow_pfn() is no
+more, and we have other users nowadays.
+
+Also extend the doc regarding refcounted pages and the interaction with
+MMU notifiers.
+
+KVM is one example that uses MMU notifiers and can deal with refcounted
+pages properly.  VFIO is one example that doesn't use MMU notifiers, and
+to prevent use-after-free, rejects refcounted pages: pfn_valid(pfn) &&
+!PageReserved(pfn_to_page(pfn)).  Protection changes are less of a concern
+for users like VFIO: the behavior is similar to longterm-pinning a page,
+and getting the PTE protection changed afterwards.
+
+The primary concern with refcounted pages is use-after-free, which callers
+should be aware of.
+
+Link: https://lkml.kernel.org/r/[email protected]
+	Signed-off-by: David Hildenbrand <[email protected]>
+	Cc: Alex Williamson <[email protected]>
+	Cc: Christoph Hellwig <[email protected]>
+	Cc: Fei Li <[email protected]>
+	Cc: Gerald Schaefer <[email protected]>
+	Cc: Heiko Carstens <[email protected]>
+	Cc: Ingo Molnar <[email protected]>
+	Cc: Paolo Bonzini <[email protected]>
+	Cc: Sean Christopherson <[email protected]>
+	Cc: Yonghua Huang <[email protected]>
+	Signed-off-by: Andrew Morton <[email protected]>
+(cherry picked from commit c5541ba378e3d36ea88bf5839d5b23e33e7d1627)
+	Signed-off-by: Jonathan Maple <[email protected]>
+
+# Conflicts:
+#	mm/memory.c
+diff --cc mm/memory.c
+index e2794e3b8919,36ba94eae853..000000000000
+--- a/mm/memory.c
++++ b/mm/memory.c
+@@@ -5623,8 -5947,7 +5630,12 @@@ int __pmd_alloc(struct mm_struct *mm, p
+   * Only IO mappings and raw PFN mappings are allowed.  The mmap semaphore
+   * should be taken for read.
+   *
+++<<<<<<< HEAD
+ + * KVM uses this function.  While it is arguably less bad than ``follow_pfn``,
+ + * it is not a good general-purpose API.
+++=======
++  * This function must not be used to modify PTE content.
+++>>>>>>> c5541ba378e3 (mm: follow_pte() improvements)
+   *
+   * Return: zero on success, -ve otherwise.
+   */
+@@@ -5637,6 -5961,13 +5648,16 @@@ int follow_pte(struct mm_struct *mm, un
+  	pmd_t *pmd;
+  	pte_t *ptep;
+  
+++<<<<<<< HEAD
+++=======
++ 	mmap_assert_locked(mm);
++ 	if (unlikely(address < vma->vm_start || address >= vma->vm_end))
++ 		goto out;
++ 
++ 	if (!(vma->vm_flags & (VM_IO | VM_PFNMAP)))
++ 		goto out;
++ 
+++>>>>>>> c5541ba378e3 (mm: follow_pte() improvements)
+  	pgd = pgd_offset(mm, address);
+  	if (pgd_none(*pgd) || unlikely(pgd_bad(*pgd)))
+  		goto out;
+* Unmerged path mm/memory.c