mm: handle device-private PMDs in walk callbacks

queue_folios_pmd() is called under pmd_trans_huge_lock(), whose pmd_is_huge() check returns true for any non-present, non-none huge PMD - including a device-private swap entry. Passing such a PMD to pmd_folio() extracts garbage bits as a PFN and returns a bogus folio pointer.

Potential trigger: an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages(), leaving a device-private PMD. Userspace then calls mbind(), migrate_pages() or set_mempolicy_home_node() on that range.

Skip device-private PMDs, matching how queue_folios_pte_range() skips device-private PTE entries by checking !pte_present().

Reported-by sashiko-bot <[email protected]>

Link https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Fixes 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations")

Signed-off-by Usama Arif <[email protected]>

---
 mm/mempolicy.c | 2 ++
 1 file changed, 2 insertions(+)

mm/mempolicy.c +0 -0

index 914f81863db5..eda817539c77 100644

Quoted 22 lines · Usama Arif

queue_folios_pmd() is called under pmd_trans_huge_lock(), whose pmd_is_huge() check returns true for any non-present, non-none huge PMD - including a device-private swap entry. Passing such a PMD to pmd_folio() extracts garbage bits as a PFN and returns a bogus folio pointer.

Potential trigger: an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages(), leaving a device-private PMD. Userspace then calls mbind(), migrate_pages() or set_mempolicy_home_node() on that range.

Skip device-private PMDs, matching how queue_folios_pte_range() skips device-private PTE entries by checking !pte_present().

Reported-by sashiko-bot <[email protected]>

Link https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Fixes 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations")

Signed-off-by Usama Arif <[email protected]>

---
 mm/mempolicy.c | 2 ++
 1 file changed, 2 insertions(+)

mm/mempolicy.c static void queue_folios_pmd(pmd_t *pmd, struct mm_walk *walk) · line 663

Quoted 10 lines

mm/mempolicy.c +2 -0

index 914f81863db5..eda817539c77 100644
@@ -659,6 +659,8 @@ static void queue_folios_pmd(pmd_t *pmd, struct mm_walk *walk)
 		qp->nr_failed++;
 		return;
 	}
+	if (unlikely(pmd_is_device_private_entry(*pmd)))
+		return;

Should it also increase qp->nr_failed like pmd migration entry above? It also applies to your "if (unlikely(pmd_is_swap_entry(*pmd)))" in the PMD-level swap patchset.

In addition, since pmd_is_huge() returns true for all non-present non-none pmds, other softleaf entries should also be excluded here? Oh, because there is no PMD level hwpoison or pmd marker.

Quoted 23 lines · Zi Yan

Quoted 22 lines · Usama Arif

queue_folios_pmd() is called under pmd_trans_huge_lock(), whose pmd_is_huge() check returns true for any non-present, non-none huge PMD - including a device-private swap entry. Passing such a PMD to pmd_folio() extracts garbage bits as a PFN and returns a bogus folio pointer.

Potential trigger: an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages(), leaving a device-private PMD. Userspace then calls mbind(), migrate_pages() or set_mempolicy_home_node() on that range.

Skip device-private PMDs, matching how queue_folios_pte_range() skips device-private PTE entries by checking !pte_present().

Reported-by sashiko-bot <[email protected]>

Link https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Fixes 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations")

Signed-off-by Usama Arif <[email protected]>

---
 mm/mempolicy.c | 2 ++
 1 file changed, 2 insertions(+)

Quoted 14 lines

mm/mempolicy.c static void queue_folios_pmd(pmd_t *pmd, struct mm_walk *walk) · line 663

Quoted 10 lines

mm/mempolicy.c +2 -0

index 914f81863db5..eda817539c77 100644
@@ -659,6 +659,8 @@ static void queue_folios_pmd(pmd_t *pmd, struct mm_walk *walk)
 		qp->nr_failed++;
 		return;
 	}
+	if (unlikely(pmd_is_device_private_entry(*pmd)))
+		return;

Should it also increase qp->nr_failed like pmd migration entry above? It also applies to your "if (unlikely(pmd_is_swap_entry(*pmd)))" in the PMD-level swap patchset.

The PTE path only increments nr_failed for migration entries, other non-present entries, including device-private and swap, are skipped. I kept things aligned with the PTE path.

Quoted 4 lines

In addition, since pmd_is_huge() returns true for all non-present non-none pmds, other softleaf entries should also be excluded here? Oh, because there is no PMD level hwpoison or pmd marker.

I think what Joshua recommended in [1] makes sense, I will change the PMD code to gate on !pmd_present() instead. That keeps migration entry accounting, skips device-private now, and will also avoid calling pmd_folio() on any future non-present PMD softleaf such as PMD swap.

[1] https://lore.kernel.org/all/[email protected]/

queue_folios_pmd() is called under pmd_trans_huge_lock(), whose pmd_is_huge() check returns true for any non-present, non-none huge PMD - including a device-private swap entry. Passing such a PMD to pmd_folio() extracts garbage bits as a PFN and returns a bogus folio pointer.

Potential trigger: an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages(), leaving a device-private PMD. Userspace then calls mbind(), migrate_pages() or set_mempolicy_home_node() on that range.

Skip device-private PMDs, matching how queue_folios_pte_range() skips device-private PTE entries by checking !pte_present().

Reported-by sashiko-bot <[email protected]>

Link https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Fixes 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations")

Signed-off-by Usama Arif <[email protected]>

---
 mm/mempolicy.c | 2 ++
 1 file changed, 2 insertions(+)

mm/mempolicy.c +0 -0

index 914f81863db5..eda817539c77 100644

madvise_cold_or_pageout_pte_range() takes pmd_trans_huge_lock(), whose pmd_is_huge() check returns true for a device-private PMD. The subsequent !pmd_present() branch has a VM_BUG_ON() asserting migration is the only allowed non-present case; a device-private PMD trips it.

Potential trigger: an HMM-based GPU driver races with madvise(MADV_COLD)/MADV_PAGEOUT: pmd_trans_huge(*pmd) reads true, then migrate_vma_pages() flips the PMD to a device-private entry before the PMD lock is acquired.

Skip device-private PMDs after taking the lock, before the !pmd_present() check.

Reported-by sashiko-bot <[email protected]>

Link https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Fixes 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations")

Signed-off-by Usama Arif <[email protected]>

---
 mm/madvise.c | 3 +++
 1 file changed, 3 insertions(+)

madvise_cold_or_pageout_pte_range() takes pmd_trans_huge_lock(), whose pmd_is_huge() check returns true for a device-private PMD. The subsequent !pmd_present() branch has a VM_BUG_ON() asserting migration is the only allowed non-present case; a device-private PMD trips it.

Potential trigger: an HMM-based GPU driver races with madvise(MADV_COLD)/MADV_PAGEOUT: pmd_trans_huge(*pmd) reads true, then migrate_vma_pages() flips the PMD to a device-private entry before the PMD lock is acquired.

Skip device-private PMDs after taking the lock, before the !pmd_present() check.

Reported-by sashiko-bot <[email protected]>

Link https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Fixes 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations")

Signed-off-by Usama Arif <[email protected]>

---
 mm/madvise.c | 3 +++
 1 file changed, 3 insertions(+)

mm/madvise.c +0 -0

index 9292f60b19aa..870be398c6f3 100644

madvise_free_pte_range() checks pmd_trans_huge(*pmd) unlocked, then madvise_free_huge_pmd() takes pmd_trans_huge_lock(). pmd_is_huge() returns true for a device-private PMD, so orig_pmd can be device-private and hit the VM_BUG_ON() on the !pmd_present() branch.

Potential trigger: an HMM-based GPU driver races with madvise(MADV_FREE):
migrate_vma_pages() flips the PMD to a device-private entry between the caller's pmd_trans_huge() check and the callee's pmd_trans_huge_lock().

Skip device-private PMDs after taking the lock, before the !pmd_present() check.

Fixes 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations")

Signed-off-by Usama Arif <[email protected]>

---
 mm/huge_memory.c | 3 +++
 1 file changed, 3 insertions(+)

madvise_free_pte_range() checks pmd_trans_huge(*pmd) unlocked, then madvise_free_huge_pmd() takes pmd_trans_huge_lock(). pmd_is_huge() returns true for a device-private PMD, so orig_pmd can be device-private and hit the VM_BUG_ON() on the !pmd_present() branch.

Potential trigger: an HMM-based GPU driver races with madvise(MADV_FREE):
migrate_vma_pages() flips the PMD to a device-private entry between the caller's pmd_trans_huge() check and the callee's pmd_trans_huge_lock().

Skip device-private PMDs after taking the lock, before the !pmd_present() check.

Fixes 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations")

Signed-off-by Usama Arif <[email protected]>

---
 mm/huge_memory.c | 3 +++
 1 file changed, 3 insertions(+)

mm/huge_memory.c +0 -0

index c0892cc533a9..cfce9f31b30e 100644

Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages().

pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VM_BUG_ON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case.

The first 2 fixes were reported as pre-existing issues by sashiko in my PMD swap entry series [1]. Hopefully sashiko won't point these out in the next PMD swap entry series :)

[1] https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Usama Arif (3):
mm/mempolicy: skip device-private PMDs when queueing folios mm/madvise: skip device-private PMDs in cold and pageout walks mm/huge_memory: skip device-private PMDs in madvise_free_huge_pmd

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

--
2.53.0-Meta

+cc Balbir

Thanks for the series!

I think Balbir should be cc'd no?

Quoted 12 lines

Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages().

pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VM_BUG_ON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case.

Quoted 3 lines

The first 2 fixes were reported as pre-existing issues by sashiko in my PMD swap entry series [1]. Hopefully sashiko won't point these out in the next PMD swap entry series :)

Yeah I don't love these 'existing problem' reports (distracting from other work, add workload, really it feels like that should be a passive reporting mode for sashiko not arbitrarily added to other series), but sending it as a separate series is indeed the right way :)

These of course should never block an unrelated series.

Quoted 2 lines

[1] https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Hmm we've had a whole host of issues with device-private PMDs recently.

Balbir - would it be possible to audit all of the code paths and proactively see if there's anything else that could hit problems here?

Quoted 6 lines

Usama Arif (3):
mm/mempolicy: skip device-private PMDs when queueing folios mm/madvise: skip device-private PMDs in cold and pageout walks mm/huge_memory: skip device-private PMDs in madvise_free_huge_pmd

Quoted 8 lines

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

--
2.53.0-Meta

Cheers, Lorenzo

I think maybe we should modify get_maintainers.pl so that if there is a "Fixes" in commit message, than the author of that commit is also in the output from that script?

Quoted 4 lines · Usama Arif

I think maybe we should modify get_maintainers.pl so that if there is a "Fixes" in commit message, than the author of that commit is also in the output from that script?

I thought it did that already, but it's forbidden perl magic that I dare not look at so who knows :P

Wasn't nagging per se about that (for once :P), often people who'd be good to cc- get missed anyway even doing all the right things, so just wanted to make sure Balbir was aware, also so we can make sure there's no other device private PMD stuff lurking! :)

Cheers, Lorenzo

+cc Balbir

Thanks for the series!

I think Balbir should be cc'd no?

Quoted 12 lines · Usama Arif

Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages().

pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VM_BUG_ON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case.

Quoted 3 lines

The first 2 fixes were reported as pre-existing issues by sashiko in my PMD swap entry series [1]. Hopefully sashiko won't point these out in the next PMD swap entry series :)

Yeah I don't love these 'existing problem' reports (distracting from other work, add workload, really it feels like that should be a passive reporting mode for sashiko not arbitrarily added to other series), but sending it as a separate series is indeed the right way :)

These of course should never block an unrelated series.

Quoted 2 lines

[1] https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Hmm we've had a whole host of issues with device-private PMDs recently.

Balbir - would it be possible to audit all of the code paths and proactively see if there's anything else that could hit problems here?

Quoted 11 lines

Usama Arif (3):
mm/mempolicy: skip device-private PMDs when queueing folios mm/madvise: skip device-private PMDs in cold and pageout walks mm/huge_memory: skip device-private PMDs in madvise_free_huge_pmd

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

Quoted 3 lines

--
2.53.0-Meta

Cheers, Lorenzo

+cc Balbir

Thanks for the series!

I think Balbir should be cc'd no?

Quoted 12 lines

Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages().

pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VM_BUG_ON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case.

Quoted 3 lines

The first 2 fixes were reported as pre-existing issues by sashiko in my PMD swap entry series [1]. Hopefully sashiko won't point these out in the next PMD swap entry series :)

Yeah I don't love these 'existing problem' reports (distracting from other work, add workload, really it feels like that should be a passive reporting mode for sashiko not arbitrarily added to other series), but sending it as a separate series is indeed the right way :)

These of course should never block an unrelated series.

Quoted 1 line

Quoted 1 line

[1] https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Hmm we've had a whole host of issues with device-private PMDs recently.

Balbir - would it be possible to audit all of the code paths and proactively see if there's anything else that could hit problems here?

Quoted 6 lines

Usama Arif (3):
mm/mempolicy: skip device-private PMDs when queueing folios mm/madvise: skip device-private PMDs in cold and pageout walks mm/huge_memory: skip device-private PMDs in madvise_free_huge_pmd

Quoted 8 lines

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

--
2.53.0-Meta

Quoted 6 lines · Lorenzo Stoakes

+cc Balbir

Thanks for the series!

I think Balbir should be cc'd no?

Thanks, my linux-mm monitoring has been largely skimming through the list. Explict cc's are always appreciated.

Quoted 28 lines · Usama Arif

Quoted 12 lines

Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages().

pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VM_BUG_ON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case.

Quoted 3 lines

The first 2 fixes were reported as pre-existing issues by sashiko in my PMD swap entry series [1]. Hopefully sashiko won't point these out in the next PMD swap entry series :)

Yeah I don't love these 'existing problem' reports (distracting from other work, add workload, really it feels like that should be a passive reporting mode for sashiko not arbitrarily added to other series), but sending it as a separate series is indeed the right way :)

These of course should never block an unrelated series.

Quoted 2 lines

[1] https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Quoted 5 lines

Hmm we've had a whole host of issues with device-private PMDs recently.

Balbir - would it be possible to audit all of the code paths and proactively see if there's anything else that could hit problems here?

Let me run through this and audit them. My usage of device private PMD did not expose them, but I can see a bunch of reports in the link above

Quoted 12 lines

Quoted 12 lines

Usama Arif (3):
mm/mempolicy: skip device-private PMDs when queueing folios mm/madvise: skip device-private PMDs in cold and pageout walks mm/huge_memory: skip device-private PMDs in madvise_free_huge_pmd

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

Quoted 4 lines

Quoted 3 lines

--
2.53.0-Meta

Thanks Lorenzo!

Balbir

Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages().

pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VM_BUG_ON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case.

The first 2 fixes were reported as pre-existing issues by sashiko in my PMD swap entry series [1]. Hopefully sashiko won't point these out in the next PMD swap entry series :)

[1] https://sashiko.dev/#/patchset/20260703173903.3789516-1-usama.arif%40linux.dev?part=6

Usama Arif (3):
mm/mempolicy: skip device-private PMDs when queueing folios mm/madvise: skip device-private PMDs in cold and pageout walks mm/huge_memory: skip device-private PMDs in madvise_free_huge_pmd

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

Signature · 1 line

2.53.0-Meta

Quoted 12 lines · On Tue, 7 Jul 2026 06:45:06 -0700 Usama Arif <[email protected]> wrote:

Since commit 368076f52ebe ("mm/huge_memory: add device-private THP support to PMD operations") a PMD may hold a device-private swap entry whenever an HMM-based GPU driver migrates an anonymous THP folio to device memory via migrate_vma_pages().

pmd_trans_huge_lock() succeeds for such PMDs (pmd_is_huge() returns true for any non-present, non-none huge PMD), so several MM walk callbacks that used to assume present THP or migration entry are now reachable with a device-private PMD. The results range from a VM_BUG_ON() firing on debug kernels, to an oops on a bogus vmemmap dereference, to silently isolating an unrelated live folio from LRU in the aliasing case.

Quoted 3 lines

The first 2 fixes were reported as pre-existing issues by sashiko in my PMD swap entry series [1]. Hopefully sashiko won't point these out in the next PMD swap entry series :)

Hello Usama,

Thank you for the fixes! I think all of them look good and they are fixes so please feel free to add my

Reviewed-by Joshua Hahn <[email protected]>

One thing I wanted to maybe consider is for 1/3, whether it could be good to gate by !pmd_present() like the sites in 2/3 and 3/3, maybe that will be more robust in the future if there are other cases we should protect against (and the same as queue_folios_pte_range, which uses the !pte_present() check too).

For 2/3 and 3/3 we already have the !pmd_present() check, would it be worth considering just changing the VM_BUG_ON condition to include !pmd_is_device_private_entry()?

Just wanted to toss my 2c. Thanks again for the fixes Usama! Joshua