Re: [PATCH] mm/page_vma_mapped: continue past nonmatching huge PMDs

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 15 Oct 2026 18:15:49 -0700 Kyle Zeng <kylebot@openai.com> wrote:

> A PTE-mapped large folio can straddle PMD boundaries after an unaligned
> mremap().  If the first part is discarded and replaced with an unrelated
> huge PMD, page_vma_mapped_walk() stops instead of looking for the rest
> of the folio in subsequent PMDs.
> 
> This also affects migration entries.  A walk that stops at an unrelated
> huge PMD can leave migration PTEs behind when migration or an anonymous
> folio split restores the mappings.  Those entries do not hold mapping
> references and can outlive the source folio.
> 
> Skip the current PMD rather than ending the walk on a flag or PFN
> mismatch.  Do the same if the PMD became nonpresent before the locked
> recheck.  Release the PMD lock, clear the per-PMD state and advance with
> step_forward(), so the existing range limit controls termination.
> This covers present, migration and device-private huge PMDs while
> preserving the matching-PMD and split-to-PTE paths.

As always, when fixing a bug please describe the worst-case
userspace-visible effects of the bug.

I asked $LLM and was told

: The worst credible effects are permanent application hangs, kernel
: crashes, and potentially system-wide denial of service.  Stale
: migration entries can refer to freed and reused physical pages, causing
: page faults to access unrelated folio metadata.  Memory corruption is
: possible but unproven; cross-process information disclosure has not
: been established.

But you have an LLM too!  So please never again send a bugfix without
this info.

Also please explain whether there's a reproducer and if so, at least
describe it and confirm the before-and-after results.

Thanks.