Re: [PATCH v4 0/4] mm/userfaultfd: modulize memory types

From: Mike Rapoport
Date: Tue Nov 11 2025 - 05:27:44 EST


On Mon, Nov 10, 2025 at 11:34:59AM -0500, Liam R. Howlett wrote:
> * Mike Rapoport <rppt@xxxxxxxxxx> [251109 02:12]:
> > On Thu, Nov 06, 2025 at 11:32:46AM -0500, Liam R. Howlett wrote:
> > > * Mike Rapoport <rppt@xxxxxxxxxx> [251104 02:22]:
> > > >
> > > > It seems that "as simple as possible" can even avoid data members in struct
> > > > vm_uffd_ops, e.g something along these lines:
> > >
> > > I like this because it removes the flag.
> > >
> > > If we don't want to return the folio, we could modify the
> > > mfill_atomic_pte_continue() to __mfill_atomic_pte_continue() which takes
> > > a function pointer and have the callers pass a different get_folio() by
> > > memory type. Each memory type (anon, shmem, and guest_memfd) would have
> > > a small stub that would be set in the vm_ops.
> >
> > I'm not sure I follow you here.
> > What do you mean by "don't want to return the folio"?
>
> I didn't get this far in my prototyping, but if we have a way to service
> the minor fault for the memory types then we could use the function
> pointer as the way to change how to get the folio vs passing in a
> pointer to get/set the folio.
>
> >
> > Isn't ->minor_get_folio() is already a different get_folio() by memory
> > type?
>
> Yes. If you are dead set with handing the folio to the module, then
> this is what you do.

uffd does not hand the folio to the module, it gets it from there.
We can make it even clearer by changing minor_get_folio() declaration to

struct folio *minor_get_folio(struct inode *inode, pgoff_t pgoff);

--
Sincerely yours,
Mike.