[PATCH v2 0/3] mm: reject zone device folios in more folio walkers

[PATCH v2 0/3] mm: reject zone device folios in more folio walkers

[Gregory Price]

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.

Gregory Price (3):
  mm/huge_memory: skip zone device folios in madvise_free_huge_pmd()
  mm/madvise: skip zone device folios in cold/pageout PMD range
  mm/mempolicy: skip zone device folios when queueing folios

 mm/huge_memory.c | 4 ++++
 mm/madvise.c     | 3 +++
 mm/mempolicy.c   | 2 ++
 3 files changed, 9 insertions(+)

---

v2 - drop hugetlb, move checks earlier in queue migration route
   - fixes tags for all 3

-- 
2.53.0-Meta

[PATCH v2 1/3] mm/huge_memory: skip zone device folios in madvise_free_huge_pmd()

[Gregory Price]

madvise_free_huge_pmd() resolves the folio backing a PMD via pmd_folio()
and marks it lazyfree without checking for zone device memory.

The surrounding guards do not cover every zone device case:
 - MADV_FREE only operates on anonymous VMAs (DAX mappings are excluded)

 - !pmd_present() branch rejects device-private and migration entries

 - present zone device PMD (device coherent THP) is not filtered.
   Unlike vm_normal_page_pmd(), it performs no special/pfnmap check,
   and would be marked lazyfree here.

Bail out when the folio is a zone device folio.

Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
Cc: stable@vger.kernel.org
Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
 mm/huge_memory.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index ced400f72d43a..714773695bbff 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2381,6 +2381,10 @@ bool madvise_free_huge_pmd(struct mmu_gather *tlb, struct vm_area_struct *vma,
 	}
 
 	folio = pmd_folio(orig_pmd);
+
+	if (folio_is_zone_device(folio))
+		goto out;
+
 	/*
 	 * If other processes are mapping this folio, we couldn't discard
 	 * the folio unless they all do MADV_FREE so let's skip the folio.
-- 
2.53.0-Meta

[PATCH v2 2/3] mm/madvise: skip zone device folios in cold/pageout PMD range

[Gregory Price]

madvise_cold_or_pageout_pte_range() resolves the folio backing a PMD
via pmd_folio() and ages or reclaims it without checking for zone
device memory.

The surrounding guards do not cover every zone device case:

  - can_madv_lru_vma() excludes VM_PFNMAP and VM_HUGETLB VMAs
    (so device DAX is filtered)

  - !pmd_present() branch above rejects device-private and
    migration entries, which are non-present.

  - A present zone device PMD - e.g. a device-coherent THP - is
    not filtered by any of these, nor by pmd_folio() (unlike
    vm_normal_page_pmd(), it performs no special/pfnmap check),
    and would be aged or paged out here.

Skip ZONE_DEVICE folios explicitly during MADV_COLD/PAGEOUT.

Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
Cc: stable@vger.kernel.org
Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
 mm/madvise.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/madvise.c b/mm/madvise.c
index c179938097bf0..2151bb9468594 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -396,6 +396,9 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
 
 		folio = pmd_folio(orig_pmd);
 
+		if (folio_is_zone_device(folio))
+			goto huge_unlock;
+
 		/* Do not interfere with other mappings of this folio */
 		if (folio_maybe_mapped_shared(folio))
 			goto huge_unlock;
-- 
2.53.0-Meta

Re: [PATCH v2 2/3] mm/madvise: skip zone device folios in cold/pageout PMD range

[Balbir Singh]

On 8/18/26 8:08 AM, Gregory Price wrote:
> madvise_cold_or_pageout_pte_range() resolves the folio backing a PMD
> via pmd_folio() and ages or reclaims it without checking for zone
> device memory.
> 
> The surrounding guards do not cover every zone device case:
> 
>   - can_madv_lru_vma() excludes VM_PFNMAP and VM_HUGETLB VMAs
>     (so device DAX is filtered)
> 
>   - !pmd_present() branch above rejects device-private and
>     migration entries, which are non-present.
> 
>   - A present zone device PMD - e.g. a device-coherent THP - is
>     not filtered by any of these, nor by pmd_folio() (unlike
>     vm_normal_page_pmd(), it performs no special/pfnmap check),
>     and would be aged or paged out here.
> 
> Skip ZONE_DEVICE folios explicitly during MADV_COLD/PAGEOUT.
> 
> Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
> Acked-by: David Hildenbrand (Arm) <david@kernel.org>
> Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
> ---
>  mm/madvise.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/mm/madvise.c b/mm/madvise.c
> index c179938097bf0..2151bb9468594 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
> @@ -396,6 +396,9 @@ static int madvise_cold_or_pageout_pte_range(pmd_t *pmd,
>  
>  		folio = pmd_folio(orig_pmd);
>  
> +		if (folio_is_zone_device(folio))
> +			goto huge_unlock;
> +
>  		/* Do not interfere with other mappings of this folio */
>  		if (folio_maybe_mapped_shared(folio))
>  			goto huge_unlock;

Makes sense

Reviewed-by: Balbir Singh <balbirs@nvidia.com>

[PATCH v2 3/3] mm/mempolicy: skip zone device folios when queueing folios

[Gregory Price]

queue_folios_pte_range() already pairs vm_normal_folio() with an
explicit folio_is_zone_device() check before adding folios to the
migration pagelist.

vm_normal_folio() alone does not reject zone device memory (a present
device-coherent page in a normal VMA is returned as "normal").

Mirror the explicit check in queue_folios_pmd() as well.

queue_folios_pmd() uses pmd_folio() directly and can encounter a present
zone device PMD - e.g. a device-coherent THP.

This is not filtered by existing checks:
  !pmd_present()   - only rejects non-present device-private and
                     migration entries

  vma_migratable() - excludes DAX and VM_PFNMAP.

The early return also means such a folio is no longer counted in
qp->nr_failed under MPOL_MF_STRICT.  This is the same pattern used
by queue_folios_pte_range() (skipping zone device without failing).

Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
Cc: stable@vger.kernel.org
Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
---
 mm/mempolicy.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/mempolicy.c b/mm/mempolicy.c
index 3498a5651d50f..3418b5664dcf8 100644
--- a/mm/mempolicy.c
+++ b/mm/mempolicy.c
@@ -662,6 +662,8 @@ static void queue_folios_pmd(pmd_t *pmd, struct mm_walk *walk)
 		return;
 	}
 	folio = pmd_folio(pmdval);
+	if (folio_is_zone_device(folio))
+		return;
 	if (is_huge_zero_folio(folio)) {
 		walk->action = ACTION_CONTINUE;
 		return;
-- 
2.53.0-Meta

Re: [PATCH v2 3/3] mm/mempolicy: skip zone device folios when queueing folios

[Balbir Singh]

On Mon, Aug 17, 2026 at 06:08:10PM -0400, Gregory Price wrote:
> queue_folios_pte_range() already pairs vm_normal_folio() with an
> explicit folio_is_zone_device() check before adding folios to the
> migration pagelist.
> 
> vm_normal_folio() alone does not reject zone device memory (a present
> device-coherent page in a normal VMA is returned as "normal").
> 
> Mirror the explicit check in queue_folios_pmd() as well.
> 
> queue_folios_pmd() uses pmd_folio() directly and can encounter a present
> zone device PMD - e.g. a device-coherent THP.
> 
> This is not filtered by existing checks:
>   !pmd_present()   - only rejects non-present device-private and
>                      migration entries
> 
>   vma_migratable() - excludes DAX and VM_PFNMAP.
> 
> The early return also means such a folio is no longer counted in
> qp->nr_failed under MPOL_MF_STRICT.  This is the same pattern used
> by queue_folios_pte_range() (skipping zone device without failing).
> 
> Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
> ---
>  mm/mempolicy.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 3498a5651d50f..3418b5664dcf8 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -662,6 +662,8 @@ static void queue_folios_pmd(pmd_t *pmd, struct mm_walk *walk)
>  		return;
>  	}
>  	folio = pmd_folio(pmdval);
> +	if (folio_is_zone_device(folio))
> +		return;
>  	if (is_huge_zero_folio(folio)) {
>  		walk->action = ACTION_CONTINUE;
>  		return;
> -- 
> 2.53.0-Meta
>


A similar patch was sent out earlier, but that was only for zone device
private THP, we don't support migration of device coherent THP today (we
should add support). The patch itself makes sense

Reviewed-by: Balbir Singh <balbirs@nvidia.com>

Re: [PATCH v2 3/3] mm/mempolicy: skip zone device folios when queueing folios

[Gregory Price]

On Tue, Aug 18, 2026 at 09:34:49AM +1000, Balbir Singh wrote:
> On Mon, Aug 17, 2026 at 06:08:10PM -0400, Gregory Price wrote:
> > 
> > diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> > index 3498a5651d50f..3418b5664dcf8 100644
> > --- a/mm/mempolicy.c
> > +++ b/mm/mempolicy.c
> > @@ -662,6 +662,8 @@ static void queue_folios_pmd(pmd_t *pmd, struct mm_walk *walk)
> >  		return;
> >  	}
> >  	folio = pmd_folio(pmdval);
> > +	if (folio_is_zone_device(folio))
> > +		return;
> >  	if (is_huge_zero_folio(folio)) {
> >  		walk->action = ACTION_CONTINUE;
> >  		return;
> > -- 
> > 2.53.0-Meta
> >
> 
> 
> A similar patch was sent out earlier, but that was only for zone device
> private THP, we don't support migration of device coherent THP today (we
> should add support). The patch itself makes sense
> 

Yeah IIRC that was Usama's and I got confused thinking this had already
been resolved - but i realized this still affects device coherent.

ty!

~Gregory

Re: [PATCH v2 3/3] mm/mempolicy: skip zone device folios when queueing folios

[Lorenzo Stoakes (ARM)]

On Mon, Aug 17, 2026 at 06:08:10PM -0400, Gregory Price wrote:
> queue_folios_pte_range() already pairs vm_normal_folio() with an
> explicit folio_is_zone_device() check before adding folios to the
> migration pagelist.
>
> vm_normal_folio() alone does not reject zone device memory (a present
> device-coherent page in a normal VMA is returned as "normal").
>
> Mirror the explicit check in queue_folios_pmd() as well.
>
> queue_folios_pmd() uses pmd_folio() directly and can encounter a present
> zone device PMD - e.g. a device-coherent THP.
>
> This is not filtered by existing checks:
>   !pmd_present()   - only rejects non-present device-private and
>                      migration entries
>
>   vma_migratable() - excludes DAX and VM_PFNMAP.
>
> The early return also means such a folio is no longer counted in
> qp->nr_failed under MPOL_MF_STRICT.  This is the same pattern used
> by queue_folios_pte_range() (skipping zone device without failing).
>
> Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>

Seems sensible so:

Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

> ---
>  mm/mempolicy.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/mm/mempolicy.c b/mm/mempolicy.c
> index 3498a5651d50f..3418b5664dcf8 100644
> --- a/mm/mempolicy.c
> +++ b/mm/mempolicy.c
> @@ -662,6 +662,8 @@ static void queue_folios_pmd(pmd_t *pmd, struct mm_walk *walk)
>  		return;
>  	}
>  	folio = pmd_folio(pmdval);
> +	if (folio_is_zone_device(folio))
> +		return;
>  	if (is_huge_zero_folio(folio)) {
>  		walk->action = ACTION_CONTINUE;
>  		return;
> --
> 2.53.0-Meta
>

--
Cheers, Lorenzo

Re: [PATCH v2 3/3] mm/mempolicy: skip zone device folios when queueing folios

[David Hildenbrand (Arm)]

On 8/18/26 00:08, Gregory Price wrote:
> queue_folios_pte_range() already pairs vm_normal_folio() with an
> explicit folio_is_zone_device() check before adding folios to the
> migration pagelist.
> 
> vm_normal_folio() alone does not reject zone device memory (a present
> device-coherent page in a normal VMA is returned as "normal").
> 
> Mirror the explicit check in queue_folios_pmd() as well.
> 
> queue_folios_pmd() uses pmd_folio() directly and can encounter a present
> zone device PMD - e.g. a device-coherent THP.
> 
> This is not filtered by existing checks:
>   !pmd_present()   - only rejects non-present device-private and
>                      migration entries
> 
>   vma_migratable() - excludes DAX and VM_PFNMAP.
> 
> The early return also means such a folio is no longer counted in
> qp->nr_failed under MPOL_MF_STRICT.  This is the same pattern used
> by queue_folios_pte_range() (skipping zone device without failing).
> 
> Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gregory Price (Meta) <gourry@gourry.net>
> ---

Acked-by: David Hildenbrand (Arm) <david@kernel.org>

-- 
Cheers,

David

Re: [PATCH v2 0/3] mm: reject zone device folios in more folio walkers

[Lance Yang]

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 <lance.yang@linux.dev>

Re: [PATCH v2 0/3] mm: reject zone device folios in more folio walkers

[Andrew Morton]

On Tue, 18 Aug 2026 12:31:43 +0800 Lance Yang <lance.yang@linux.dev> wrote:

> 
> 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 <lance.yang@linux.dev>

Thanks Lance, you're so diligent.

I'm wondering what to do here.  Gregory told us

: 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.

And you had to tweak the hmm-test driver to reproduce the bug(s).

So when do we push this series out to -stable?  As a hair-on-fire
hotfix, or as a leisurely next-merge-window thing?


And Sashiko was clearly having a bad day, able to find only nine
pre-existing things to shout about:
	https://sashiko.dev/#/patchset/20260817220810.1175596-1-gourry@gourry.net

Re: [PATCH v2 0/3] mm: reject zone device folios in more folio walkers

[Lance Yang]

On 2026/8/30 08:18, Andrew Morton wrote:
> On Tue, 18 Aug 2026 12:31:43 +0800 Lance Yang <lance.yang@linux.dev> wrote:
> 
>>
>> 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 <lance.yang@linux.dev>
> 
> Thanks Lance, you're so diligent.
> 
> I'm wondering what to do here.  Gregory told us
> 
> : 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.
> 
> And you had to tweak the hmm-test driver to reproduce the bug(s).
> 
> So when do we push this series out to -stable?  As a hair-on-fire
> hotfix, or as a leisurely next-merge-window thing?

Thanks, Andrew :) Yeah, I'd say next merge window should be fine :)

The crash is real once the mapping exists, but I had to tweak test_hmm
to create that PMD-mapped device-coherent folio, and I couldn't find
any in-tree production driver doing that today.

So no need to rush this one, I guess.

> 
> And Sashiko was clearly having a bad day, able to find only nine
> pre-existing things to shout about:
> 	https://sashiko.dev/#/patchset/20260817220810.1175596-1-gourry@gourry.net
> 

Re: [PATCH v2 0/3] mm: reject zone device folios in more folio walkers

[Lance Yang]

On Sun, Aug 30, 2026 at 01:18:24PM +0800, Lance Yang wrote:
>
>
>On 2026/8/30 08:18, Andrew Morton wrote:
>> On Tue, 18 Aug 2026 12:31:43 +0800 Lance Yang <lance.yang@linux.dev> wrote:
>> 
>>>
>>> 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 <lance.yang@linux.dev>
>> 
>> Thanks Lance, you're so diligent.
>> 
>> I'm wondering what to do here.  Gregory told us
>> 
>> : 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.
>> 
>> And you had to tweak the hmm-test driver to reproduce the bug(s).
>> 
>> So when do we push this series out to -stable?  As a hair-on-fire
>> hotfix, or as a leisurely next-merge-window thing?
>
>Thanks, Andrew :) Yeah, I'd say next merge window should be fine :)
>
>The crash is real once the mapping exists, but I had to tweak test_hmm
>to create that PMD-mapped device-coherent folio, and I couldn't find
>any in-tree production driver doing that today.
>
>So no need to rush this one, I guess.

BTW, noticed that the ZONE_DEVICE split handling only covers
device-private folios, so device-coherent folios aren't supported ...

The call chains are:

split_folio()
  -> __folio_split()
    -> folio_check_splittable()
    -> __folio_freeze_and_split_unmapped()

migrate_vma_pages()
  -> __migrate_device_pages()
    -> migrate_vma_split_unmapped_folio()
      -> folio_split_unmapped()
        -> __folio_freeze_and_split_unmapped()

And I added the device-coherent check to folio_check_splittable() and
folio_split_unmapped(). See below. They can go away once device-coherent
folio splitting is supported :)

If folks think it's worth having, I can send it as a follow-up :)

---8<---
Subject: [PATCH] mm/huge_memory: don't split device-coherent folios

From: Lance Yang <lance.yang@linux.dev>

The ZONE_DEVICE split handling only covers device-private folios.
Device-coherent folios are not supported.

The call chains are:

split_folio()
  -> __folio_split()
    -> folio_check_splittable()
    -> __folio_freeze_and_split_unmapped()

migrate_vma_pages()
  -> __migrate_device_pages()
    -> migrate_vma_split_unmapped_folio()
      -> folio_split_unmapped()
        -> __folio_freeze_and_split_unmapped()

Reject device-coherent folios in folio_check_splittable() and
folio_split_unmapped().

Fixes: a30b48bf1b24 ("mm/migrate_device: implement THP migration of zone device pages")
Signed-off-by: Lance Yang <lance.yang@linux.dev>
---
 mm/huge_memory.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 54494c3fa983..a5dd38e9a8de 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -3937,6 +3937,10 @@ int folio_check_splittable(struct folio *folio, unsigned int new_order,
 	if (!folio->mapping && !folio_test_anon(folio))
 		return -EBUSY;

+	/* TODO: Support splitting device-coherent folios. */
+	if (folio_is_device_coherent(folio))
+		return -EOPNOTSUPP;
+
 	/* order-1 is not supported for anonymous THP. */
 	if (folio_test_anon(folio) && new_order == 1)
 		return -EINVAL;
@@ -4354,15 +4358,16 @@ static int __folio_split(struct folio *folio, unsigned int new_order,
  *
  * anon_vma_lock is not required to be held, mmap_read_lock() or
  * mmap_write_lock() should be held. @folio is expected to be locked by the
- * caller. device-private and non device-private folios are supported along
+ * caller. device-private and non-ZONE_DEVICE folios are supported along
  * with folios that are in the swapcache. @folio should also be unmapped and
  * isolated from LRU (if applicable)
  *
  * Upon return, the folio is not remapped, split folios are not added to LRU,
  * free_folio_and_swap_cache() is not called, and new folios remain locked.
  *
- * Return: 0 on success, -EAGAIN if the folio cannot be split (e.g., due to
- *         insufficient reference count or extra pins).
+ * Return: 0 on success, -EOPNOTSUPP for device-coherent folios, or -EAGAIN if
+ *         the folio cannot be split (e.g., due to insufficient reference
+ *         count or extra pins).
  */
 int folio_split_unmapped(struct folio *folio, unsigned int new_order)
 {
@@ -4373,6 +4378,9 @@ int folio_split_unmapped(struct folio *folio, unsigned int new_order)
 	VM_WARN_ON_ONCE_FOLIO(!folio_test_large(folio), folio);
 	VM_WARN_ON_ONCE_FOLIO(!folio_test_anon(folio), folio);

+	if (folio_is_device_coherent(folio))
+		return -EOPNOTSUPP;
+
 	if (folio_expected_ref_count(folio) != folio_ref_count(folio) - 1)
 		return -EAGAIN;

--

Cheers, Lance