Re: [PATCH mm-hotfixes v3 3/4] mm/ptdump: always stabilise against page table freeing using init_mm

[David Hildenbrand (Arm)]

On 7/14/26 19:24, Lorenzo Stoakes wrote:
> Previous commits have established the invariant that kernel page table
> freeing is performed while an mmap read lock on init_mm is held, which
> fixes races between ptdump and kernel page table freeing over init_mm.
> 
> However, x86 and arm64 can perform a ptdump over an mm other than init_mm
> via ptdump_walk_pgd() and since kernel memory ranges are shared across
> non-kernel mm's, this means that the race still exists for these cases.
> 
> Fix this by acquiring a nested mmap write lock for init_mm in
> ptdump_walk_pgd().
> 
> This is safe as we take this after mmap write locking the mm, and nothing
> acquires the init_mm lock first before locking an arbitrary mm, so no
> deadlock is possible.
> 
> Also update walk_page_range_debug() to assert that init_mm is write locked,
> add a comment explaining why and remove some redundant code, and eliminate
> the unnecessary and confusing invocation of walk_kernel_page_table_range().
> 
> We can safely remove the non-NULL check for walk.mm, as the mmap lock
> asserts would NULL pointer deref if it was (and of course no callers do
> this).
> 
> The first point at which ptdump can race kernel page table freeing is
> commit b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page
> table"), so we target this in the Fixes tag.
> 
> Fixes: b6bdb7517c3d ("mm/vmalloc: add interfaces to free unmapped page table")
> Cc: stable@xxxxxxxxxxxxxxx
> Reviewed-by: Mike Rapoport (Microsoft) <rppt@xxxxxxxxxx>
> Signed-off-by: Lorenzo Stoakes <ljs@xxxxxxxxxx>

All that complexity for a debug feature :)

Acked-by: David Hildenbrand (Arm) <david@xxxxxxxxxx>

-- 
Cheers,

David