On Mon, Nov 17, 2025 at 06:08:57PM +0100, David Hildenbrand (Red Hat) wrote:
> On 17.11.25 12:46, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)" <[email protected]>
> >
> > When userspace resolves a page fault in a shmem VMA with UFFDIO_CONTINUE
> > it needs to get a folio that already exists in the pagecache backing
> > that VMA.
> >
> > Instead of using shmem_get_folio() for that, add a get_pagecache_folio()
> > method to 'struct vm_operations_struct' that will return a folio if it
> > exists in the VMA's pagecache at given pgoff.
> >
> > Implement get_pagecache_folio() method for shmem and slightly refactor
> > userfaultfd's mfill_atomic() and mfill_atomic_pte_continue() to support
> > this new API.
> >
> > Signed-off-by: Mike Rapoport (Microsoft) <[email protected]>
> > ---
> > include/linux/mm.h | 9 +++++++
> > mm/shmem.c | 20 ++++++++++++++++
> > mm/userfaultfd.c | 60 ++++++++++++++++++++++++++++++----------------
> > 3 files changed, 69 insertions(+), 20 deletions(-)
> >
> > diff --git a/include/linux/mm.h b/include/linux/mm.h
> > index d16b33bacc32..c35c1e1ac4dd 100644
> > --- a/include/linux/mm.h
> > +++ b/include/linux/mm.h
> > @@ -690,6 +690,15 @@ struct vm_operations_struct {
> > struct page *(*find_normal_page)(struct vm_area_struct *vma,
> > unsigned long addr);
> > #endif /* CONFIG_FIND_NORMAL_PAGE */
> > +#ifdef CONFIG_USERFAULTFD
> > + /*
> > + * Called by userfault to resolve UFFDIO_CONTINUE request.
> > + * Should return the folio found at pgoff in the VMA's pagecache if it
> > + * exists or ERR_PTR otherwise.
> > + */
>
> What are the locking +refcount rules? Without looking at the code, I would
> assume we return with a folio reference held and the folio locked?
Right, will add it to the comment
> > + struct folio *(*get_pagecache_folio)(struct vm_area_struct *vma,
> > + pgoff_t pgoff);
>
>
> The combination of VMA + pgoff looks weird at first. Would vma + addr or
> vma+vma_offset into vma be better?
Copied from map_pages() :)
> But it also makes me wonder if the callback would ever even require the VMA,
> or actually only vma->vm_file?
It's actually inode, I'm going to pass that instead of vma.
> Thinking out loud, I wonder if one could just call that "get_folio" or
> "get_shared_folio" (IOW, never an anon folio in a MAP_PRIVATE mapping).
Naming is hard :)
get_shared_folio() sounds good to me so unless there other suggestions I'll
stick with it.
> > +#endif
> > };
> > #ifdef CONFIG_NUMA_BALANCING
...
> > +static __always_inline bool vma_can_mfill_atomic(struct vm_area_struct
> > *vma,
> > + uffd_flags_t flags)
> > +{
> > + if (uffd_flags_mode_is(flags, MFILL_ATOMIC_CONTINUE)) {
> > + if (vma->vm_ops && vma->vm_ops->get_pagecache_folio)
> > + return true;
> > + else
> > + return false;
>
> Probably easier to read is
>
> return vma->vm_ops && vma->vm_ops->get_pagecache_folio;
>
> > + }
> > +
> > + if (vma_is_anonymous(vma) || vma_is_shmem(vma))
> > + return true;
> > +
> > + return false;
>
>
> Could also be simplified to:
>
> return vma_is_anonymous(vma) || vma_is_shmem(vma);
Agree with for both of them.
> --
> Cheers
>
> David
--
Sincerely yours,
Mike.
