[PATCH 30/46] mm/mremap: recheck PUDs under the page table lock

sashiko-bot at kernel.org sashiko-bot at kernel.org
Mon Oct 26 17:13:37 PDT 2026


> 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 at vger.kernel.org
> Reviewed-by: Lorenzo Stoakes (ARM) <ljs at kernel.org>
> Signed-off-by: David Hildenbrand (Arm) <david at kernel.org>

Sashiko has reviewed this patch and found no issues.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261027-fixes_core-v1-0-6f74bec9a5bb@kernel.org?part=30




More information about the kexec mailing list