diff mbox series

[v3,13/16] mm/gup: disallow follow_page(FOLL_PIN)

Message ID 20220329160440.193848-14-david@redhat.com (mailing list archive)
State New
Headers show
Series mm: COW fixes part 2: reliable GUP pins of anonymous pages | expand

Commit Message

David Hildenbrand March 29, 2022, 4:04 p.m. UTC
We want to change the way we handle R/O pins on anonymous pages that
might be shared: if we detect a possibly shared anonymous page --
mapped R/O and not !PageAnonExclusive() -- we want to trigger unsharing
via a page fault, resulting in an exclusive anonymous page that can be
pinned reliably without getting replaced via COW on the next write
fault.

However, the required page fault will be problematic for follow_page():
in contrast to ordinary GUP, follow_page() doesn't trigger faults
internally. So we would have to end up failing a R/O pin via
follow_page(), although there is something mapped R/O into the page
table, which might be rather surprising.

We don't seem to have follow_page(FOLL_PIN) users, and it's a purely
internal MM function. Let's just make our life easier and the semantics of
follow_page() clearer by just disallowing FOLL_PIN for follow_page()
completely.

Signed-off-by: David Hildenbrand <david@redhat.com>
---
 mm/gup.c     | 3 +++
 mm/hugetlb.c | 8 +++++---
 2 files changed, 8 insertions(+), 3 deletions(-)

Comments

Vlastimil Babka April 14, 2022, 3:18 p.m. UTC | #1
On 3/29/22 18:04, David Hildenbrand wrote:
> We want to change the way we handle R/O pins on anonymous pages that
> might be shared: if we detect a possibly shared anonymous page --
> mapped R/O and not !PageAnonExclusive() -- we want to trigger unsharing
> via a page fault, resulting in an exclusive anonymous page that can be
> pinned reliably without getting replaced via COW on the next write
> fault.
> 
> However, the required page fault will be problematic for follow_page():
> in contrast to ordinary GUP, follow_page() doesn't trigger faults
> internally. So we would have to end up failing a R/O pin via
> follow_page(), although there is something mapped R/O into the page
> table, which might be rather surprising.
> 
> We don't seem to have follow_page(FOLL_PIN) users, and it's a purely
> internal MM function. Let's just make our life easier and the semantics of
> follow_page() clearer by just disallowing FOLL_PIN for follow_page()
> completely.
> 
> Signed-off-by: David Hildenbrand <david@redhat.com>

Acked-by: Vlastimil Babka <vbabka@suse.cz>
diff mbox series

Patch

diff --git a/mm/gup.c b/mm/gup.c
index 271fbe8195d7..f96fc415ea6c 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -787,6 +787,9 @@  struct page *follow_page(struct vm_area_struct *vma, unsigned long address,
 	if (vma_is_secretmem(vma))
 		return NULL;
 
+	if (foll_flags & FOLL_PIN)
+		return NULL;
+
 	page = follow_page_mask(vma, address, foll_flags, &ctx);
 	if (ctx.pgmap)
 		put_dev_pagemap(ctx.pgmap);
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 6910545f028e..75b689ce21c5 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -6698,9 +6698,11 @@  follow_huge_pmd(struct mm_struct *mm, unsigned long address,
 	spinlock_t *ptl;
 	pte_t pte;
 
-	/* FOLL_GET and FOLL_PIN are mutually exclusive. */
-	if (WARN_ON_ONCE((flags & (FOLL_PIN | FOLL_GET)) ==
-			 (FOLL_PIN | FOLL_GET)))
+	/*
+	 * FOLL_PIN is not supported for follow_page(). Ordinary GUP goes via
+	 * follow_hugetlb_page().
+	 */
+	if (WARN_ON_ONCE(flags & FOLL_PIN))
 		return NULL;
 
 retry: