[RFC v1 1/3] mm/mmu_notifier: Add a new notifier for mapping updates (new pages)

Jason Gunthorpe jgg at nvidia.com
Fri Aug 4 12:49:28 UTC 2023


On Fri, Aug 04, 2023 at 06:39:22AM +0000, Kasireddy, Vivek wrote:

> No, adding HMM_PFN_REQ_WRITE still doesn't help in fixing the issue.
> Although, I do not have THP enabled (or built-in), shmem does not evict
> the pages after hole punch as noted in the comment in shmem_fallocate():

This is the source of all your problems.

Things that are mm-centric are supposed to track the VMAs and changes to
the PTEs. If you do something in userspace and it doesn't cause the
CPU page tables to change then it certainly shouldn't cause any mmu
notifiers or hmm_range_fault changes.

There should still be an invalidation notifier at some point when the
CPU tables do eventually change, whenever that is. Missing that
notification would be a bug.

> If I force it to read-fault or write-fault (by hacking hmm_pte_need_fault()),
> it gets indefinitely stuck in the do while loop in hmm_range_fault().
> AFAIU, unless there is a way to fault-in zero pages (or any scratch pages)
> after hole punch that get invalidated because of writes, I do not see how
> using hmm_range_fault() can help with my use-case. 

hmm_range_fault() is the correct API to use if you are working with
notifiers. Do not hack something together using pin_user_pages.

Jason


More information about the dri-devel mailing list