Re: [PATCH 1/4] mm: Introduce vm_uffd_ops API

[Peter Xu <peterx@redhat.com>]

On Mon, Jun 23, 2025 at 06:50:42PM +0200, David Hildenbrand wrote:
> On 23.06.25 15:59, Peter Xu wrote:
> > On Mon, Jun 23, 2025 at 10:25:33AM +0200, David Hildenbrand wrote:
> > > On 20.06.25 21:03, Peter Xu wrote:
> > > 
> > > Hi Peter,
> > 
> > Hey David,
> > 
> > > 
> > > > Introduce a generic userfaultfd API for vm_operations_struct, so that one
> > > > vma, especially when as a module, can support userfaults without modifying
> > > 
> > > The sentence is confusing ("vma ... as a module").
> > > 
> > > Did you mean something like ".. so that a vma that is backed by a
> > > special-purpose in-memory filesystem like shmem or hugetlb can support
> > > userfaultfd without modifying the uffd core; this is required when the
> > > in-memory filesystem is built as a module."
> > 
> > I wanted to avoid mentioning of "in-memory file systems" here.
> 
> I thought one of the challenges of supporting guest_memfd on anything that
> is not a special in-memory file system is also related to how the pagecache
> handles readahead.
> 
> So ...

See uffd_disable_fault_around(). We should make sure no such happens into
pgtables when some special type of file is suppoorted, if it ever happens,
besides shmem.  IIUC readahead on page caches are fine for non-MISSING
traps.  So a file can support MINOR, for example, but then it'll also need
to make sure all those aspected are well considered.

> 
> > 
> > How about an updated commit like this?
> > 
> >    Currently, most of the userfaultfd features are implemented directly in the
> >    core mm.  It will invoke VMA specific functions whenever necessary.  So far
> >    it is fine because it almost only interacts with shmem and hugetlbfs.
> > 
> >    This patch introduces a generic userfaultfd API for vm_operations_struct,
> >    so that any type of file (including kernel modules that can be compiled
> >    separately from the kernel core) can support userfaults without modifying
> >    the core files.
> 
> .... is it really "any file" ? I doubt it, but you likely have a better idea
> on how it all could just work with "any file".
> 
> > 
> >    After this API applied, if a module wants to support userfaultfd, the
> >    module should only need to touch its own file and properly define
> >    vm_uffd_ops, instead of changing anything in core mm.
> > 
> >    ...
> 
> Talking about files and modules is still confusing I'm afraid. It's really a
> special-purpose file (really, not any ordinary files on ordinary
> filesystems), no?

One major reason I wanted to avoid the term "in-memory" is that we already
support most of the files on WP_ASYNC, so emphasizing on in-memory might be
misleading, even though WP_ASYNC isn't much taken into the picture of the
vm_uffd_ops being proposed.

The other thing is, besides the original form of userfaultfd (which is the
MISSING traps), almost all the rest (sync-wp, continue, poison, maybe even
MOVE but that's still more special) should be at least logically doable on
most of the files like WP_ASYNC.  When proposing this API, I wanted to make
it as generic as possible when people reading about it.  Hope that makes
sense.

Thanks,

-- 
Peter Xu