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

From: Pedro Falcato

Date: Wed Oct 28 2026 - 09:29:27 EST


On Tue, Oct 27, 2026 at 12:17:50AM +0100, David Hildenbrand (Arm) wrote:
> 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@xxxxxxxxxxxxxxx
> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@xxxxxxxxxx>
> Signed-off-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

Reviewed-by: Pedro Falcato <pfalcato@xxxxxxx>

--
Pedro