From: Sasha Levin <sashal@kernel.org>
To: stable@vger.kernel.org
Cc: "David Hildenbrand (Arm)" <david@kernel.org>,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
Pedro Falcato <pfalcato@suse.de>,
Muhammad Usama Anjum <usama.anjum@arm.com>,
Lance Yang <lance.yang@linux.dev>,
Sasha Levin <sashal@kernel.org>
Subject: [PATCH 6.6.y] mm/mremap: recheck PUDs under the page table lock
Date: Thu, 12 Nov 2026 14:59:32 -0500 [thread overview]
Message-ID: <20261112195747.3385807-1-sashal@kernel.org> (raw)
In-Reply-To: <20261109201344-failed-6.6-402882943dfa@kernel.org>
From: "David Hildenbrand (Arm)" <david@kernel.org>
[ Upstream commit 402882943dfa8bab5c2bcc66189f9fb2828f248e ]
Once get_old_pud() is fixed to accept PUD leaves, unmap_mapping_range() can
clear a leaf between the lookup and the move. Holding mmap_lock in write
mode does not prevent this.
If the zap happens before move_page_tables() tests the entry, an empty
PUD can reach move_normal_pud(), where pud_populate() turns it into a
present page table entry. If it happens after the test, move_huge_pud()
can instead try to move an empty entry, triggering CONFIG_DEBUG_VM
warnings on powerpc.
Recheck the source under the page table lock in both helpers. Treat an
empty source in move_normal_pud() as a completed move, and use
__pud_trans_huge_lock() in move_huge_pud().
In the future we should likely have the code lookup a PUD/PMD lockless
once, instead of multiple times, because one of the problematic bits
here is the:
pud_trans_huge(*old_pud)
Fixes: 0881ace292b6 ("mm/mremap: use pmd/pud_poplulate to update page table entries")
Cc: stable@vger.kernel.org
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Tested-by: Muhammad Usama Anjum <usama.anjum@arm.com>
Link: https://patch.msgid.link/20261031-fixes_core-v3-31-d6437171ecc3@kernel.org
Reviewed-by: Lance Yang <lance.yang@linux.dev>
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
[ sashal: adjusted context for move functions using explicit vma and old_addr parameters instead of pagetable_move_control ]
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
mm/mremap.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/mm/mremap.c b/mm/mremap.c
index 0739a31b54eed..be6b4aab93bd2 100644
--- a/mm/mremap.c
+++ b/mm/mremap.c
@@ -363,14 +363,18 @@ static bool move_normal_pud(struct vm_area_struct *vma, unsigned long old_addr,
if (new_ptl != old_ptl)
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
- /* Clear the pud */
pud = *old_pud;
+ if (unlikely(pud_none(pud)))
+ goto out_unlock;
+
+ /* Clear the pud */
pud_clear(old_pud);
VM_BUG_ON(!pud_none(*new_pud));
pud_populate(mm, new_pud, pud_pgtable(pud));
flush_tlb_range(vma, old_addr, old_addr + PUD_SIZE);
+out_unlock:
if (new_ptl != old_ptl)
spin_unlock(new_ptl);
spin_unlock(old_ptl);
@@ -405,7 +409,9 @@ static bool move_huge_pud(struct vm_area_struct *vma, unsigned long old_addr,
* We don't have to worry about the ordering of src and dst
* ptlocks because exclusive mmap_lock prevents deadlock.
*/
- old_ptl = pud_lock(vma->vm_mm, old_pud);
+ old_ptl = __pud_trans_huge_lock(old_pud, vma);
+ if (unlikely(!old_ptl))
+ return false;
new_ptl = pud_lockptr(mm, new_pud);
if (new_ptl != old_ptl)
spin_lock_nested(new_ptl, SINGLE_DEPTH_NESTING);
--
2.53.0
prev parent reply other threads:[~2026-11-12 19:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-10 1:13 FAILED: patch "[PATCH] mm/mremap: recheck PUDs under the page table lock" failed to apply to 6.6-stable tree Sasha Levin
2026-11-12 19:59 ` Sasha Levin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20261112195747.3385807-1-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=david@kernel.org \
--cc=lance.yang@linux.dev \
--cc=ljs@kernel.org \
--cc=pfalcato@suse.de \
--cc=stable@vger.kernel.org \
--cc=usama.anjum@arm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.