Skip to contentSkip to conversation

mm-hugetlb-remove-hugetlb_follow_page_mask-leftover.patch removed from -mm tree

merged mm-stable Andrew Morton 1 participant 1 message Sep 2, 2024

lore
Share & tools
lore

Andrew Morton

author tree notice Applied
#0 lore raw

The quilt patch titled
Subject: mm/hugetlb: remove hugetlb_follow_page_mask() leftover
has been removed from the -mm tree. Its filename was
mm-hugetlb-remove-hugetlb_follow_page_mask-leftover.patch

This patch was dropped because it was merged into the mm-stable branch of git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm

------------------------------------------------------
From: David Hildenbrand <[email protected]>
Subject: mm/hugetlb: remove hugetlb_follow_page_mask() leftover
Date: Wed, 31 Jul 2024 16:20:00 +0200

We removed hugetlb_follow_page_mask() in commit 9cb28da54643 ("mm/gup:
handle hugetlb in the generic follow_page_mask code") but forgot to cleanup some leftovers.

While at it, simplify the hugetlb comment, it's overly detailed and rather confusing. Stating that we may end up in there during coredumping is sufficient to explain the PF_DUMPCORE usage.

Link https://lkml.kernel.org/r/[email protected] open here
Signed-off-by David Hildenbrand <[email protected]>
Reviewed-by Peter Xu <[email protected]>
Cc Muchun Song <[email protected]>
Cc Alexander Viro <[email protected]>
Cc Christian Brauner <[email protected]>
Cc Jan Kara <[email protected]>
Signed-off-by Andrew Morton <[email protected]>

---

 fs/userfaultfd.c        |   11 ++---------
 include/linux/hugetlb.h |    3 ---
 2 files changed, 2 insertions(+), 12 deletions(-)
fs/userfaultfd.c renamed from fs/userfaultfd.c~mm-hugetlb-remove-hugetlb_follow_page_mask-leftover +2 -9
@@ -371,15 +371,8 @@ vm_fault_t handle_userfault(struct vm_fa
 	unsigned int blocking_state;
 
 	/*
-	 * We don't do userfault handling for the final child pid update.
-	 *
-	 * We also don't do userfault handling during
-	 * coredumping. hugetlbfs has the special
-	 * hugetlb_follow_page_mask() to skip missing pages in the
-	 * FOLL_DUMP case, anon memory also checks for FOLL_DUMP with
-	 * the no_page_table() helper in follow_page_mask(), but the
-	 * shmem_vm_ops->fault method is invoked even during
-	 * coredumping and it ends up here.
+	 * We don't do userfault handling for the final child pid update
+	 * and when coredumping (faults triggered by get_dump_page()).
 	 */
 	if (current->flags & (PF_EXITING|PF_DUMPCORE))
 		goto out;
include/linux/hugetlb.h renamed from include/linux/hugetlb.h~mm-hugetlb-remove-hugetlb_follow_page_mask-leftover +0 -3
@@ -127,9 +127,6 @@ int move_hugetlb_page_tables(struct vm_a
 			     unsigned long len);
 int copy_hugetlb_page_range(struct mm_struct *, struct mm_struct *,
 			    struct vm_area_struct *, struct vm_area_struct *);
-struct page *hugetlb_follow_page_mask(struct vm_area_struct *vma,
-				      unsigned long address, unsigned int flags,
-				      unsigned int *page_mask);
 void unmap_hugepage_range(struct vm_area_struct *,
 			  unsigned long, unsigned long, struct page *,
 			  zap_flags_t);

_

Patches currently in -mm which might be from [email protected] are

mm-rmap-use-folio-_mapcount-for-small-folios.patch mm-always-inline-_compound_head-with-config_hugetlb_page_optimize_vmemmap=y.patch selftests-mm-fix-charge_reserved_hugetlbsh-test.patch