Re: [PATCH 0/3] mm: handle device-private PMDs in walk callbacks

[Lorenzo Stoakes]

On Wed, Jul 08, 2026 at 08:57:51AM +1000, Balbir Singh wrote:
> On Tue, Jul 07, 2026 at 03:01:56PM +0100, Lorenzo Stoakes wrote:
> > +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.

Honestly I don't know how you do it, I gave up on linux-mm a long time ago and
pretty much rely on cc- now (which isn't always perfect ofc... :)

>
> > On Tue, Jul 07, 2026 at 06:45:06AM -0700, Usama Arif 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.
> > >
> > > 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.
> >
> > >
> > > [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?
> >
>
> 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

Great thanks :)

>
> > >
> > > 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
> > >
> >
>
> Thanks Lorenzo!

You're welcome! :)

>
> Balbir

Cheers, Lorenzo