FAILED: patch "[PATCH] mm/rmap: use huge_ptep_get() in try_to_migrate_one()" failed to apply to 5.15-stable tree
Subsystems (3)
[email protected]
maintainerThe patch below does not apply to the 5.15-stable tree.
If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <[email protected]>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-5.15.y
git checkout FETCH_HEAD
git cherry-pick -x 9be12ffa78cd087d41086f937a156435d4e588e9
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<[email protected]>' --in-reply-to '2026090300-awry-struggle-b110@gregkh' --subject-prefix 'PATCH 5.15.y' 'HEAD^..'
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 9be12ffa78cd087d41086f937a156435d4e588e9 Mon Sep 17 00:00:00 2001
From: Dev Jain <[email protected]>
Date: Fri, 3 Jul 2026 11:41:56 +0000
Subject: [PATCH] mm/rmap: use huge_ptep_get() in try_to_migrate_one()
try_to_migrate_one() is used by folio migration to replace a present mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads the huge pte entry with ptep_get().
On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.
It is not clear whether this has a trivially visible effect to userspace.
Use huge_ptep_get() to dereference a huge pte pointer.
Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into try_to_migrate_one.
mm/rmap.c +9 -6
@@ -2500,14 +2500,18 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma,/* Unexpected PMD-mapped THP? */ VM_BUG_ON_FOLIO (!pvmw.pte, folio); -/* -* Handle PFN swap PTEs, such as device-exclusive ones, that -* actually map pages. -*/ - pteval =ptep_get (pvmw.pte); + address = pvmw.address; +if (folio_test_hugetlb (folio)) + pteval =huge_ptep_get (mm, address, pvmw.pte); +else + pteval =ptep_get (pvmw.pte);if (likely (pte_present (pteval))) { pfn =pte_pfn (pteval); }else { +/* +* Handle PFN swap PTEs, such as device-exclusive ones, +* that actually map pages. +*/ const softleaf_t entry =softleaf_from_pte (pteval); pfn =softleaf_to_pfn (entry);
@@ -2515,7 +2519,6 @@ static bool try_to_migrate_one(struct folio *folio, struct vm_area_struct *vma, } subpage =folio_page (folio, pfn -folio_pfn (folio)); - address = pvmw.address; anon_exclusive =folio_test_anon (folio) &&PageAnonExclusive (subpage);
Sasha Levin
maintainerPATCH 1/1 mm/rmap: use huge_ptep_get() in try_to_migrate_one()
From: Dev Jain <[email protected]>
[ Upstream commit 9be12ffa78cd087d41086f937a156435d4e588e9 ]
try_to_migrate_one() is used by folio migration to replace a present mapping with a migration entry. For hugetlb folios, page_vma_mapped_walk() returns the pte pointer to the hugetlb folio in pvmw.pte, but the code reads the huge pte entry with ptep_get().
On arches which provide their own huge_ptep_get() to dereference a huge pte pointer, accessing via ptep_get() would cause pte_pfn(), pte_present() etc to misbehave.
It is not clear whether this has a trivially visible effect to userspace.
Use huge_ptep_get() to dereference a huge pte pointer.
Commit a98a2f0c8ce1 copied the bug from try_to_unmap_one into try_to_migrate_one.
--- mm/rmap.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
mm/rmap.c +5 -1
@@ -1784,7 +1784,11 @@ static bool try_to_migrate_one(struct page *page, struct vm_area_struct *vma,/* Unexpected PMD-mapped THP? */ VM_BUG_ON_PAGE (!pvmw.pte, page); - subpage = page -page_to_pfn (page) +pte_pfn (*pvmw.pte); +if (PageHuge (page)) + pteval =huge_ptep_get (pvmw.pte); +else + pteval = *pvmw.pte; + subpage = page -page_to_pfn (page) +pte_pfn (pteval); address = pvmw.address;if (PageHuge (page) && !PageAnon (page)) {
Signature · 1 line
2.53.0