Re: [PATCH v2 0/3] mm: reject zone device folios in more folio walkers
Lance Yang <[email protected]>
| Newsgroups | org.kvack.linux-mm,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, Aug 17, 2026 at 06:08:07PM -0400, Gregory Price wrote: >Several LRU-oriented mm walkers resolve the folio backing a PMD entry >(or a physical pfn) and then reclaim, age, migrate, or lazyfree it >without ever checking for ZONE_DEVICE memory. > >This series adds missing folio_is_zone_device() rejections, matching >the checks that comparable walkers already perform. > >- mm/huge_memory, mm/madvise: the !pmd_present branch above these sites > only filters device-private entries (which are non-present). > > A present zone device PMD (e.g. device-coherent) would still reach the > folio and be lazyfreed / aged / paged out. Add an explicit check. > >- mm/mempolicy: queue_folios_pmd() can see a present zone device PMD > (e.g. device-coherent) and queue it for migration. > >No crash reproducer - this is a correctness/hardening cleanup found by >inspection. All checks are placed after the folio is resolved and before >it is acted upon, on paths that already hold the relevant page-table lock, >so no locking or refcount changes are involved. Cool! Gave the whole series a spin on x86_64 QEMU with a PMD-mapped device-coherent THP. Without these patches, partial MADV_FREE and MADV_COLD reliably hit a kernel panic in remove_migration_pte(), while mbind(MPOL_MF_MOVE | MPOL_MF_STRICT) returned -EIO. With v2, all three worked fine, PMD mapping stayed intact, and data checked out :) Note that both kernels used the same small change to the in-kernel HMM test driver, allowing its coherent device memory to be allocated as 2 MB folios so the PMD-mapped test case could be exercised. Tested-by: Lance Yang <[email protected]>