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

[Peter Xu <peterx@redhat.com>]

On Tue, Oct 07, 2025 at 04:25:48PM -0400, Liam R. Howlett wrote:
> > Would it look better to you if I drop uffd_modes_supported, deducing it
> > from uffd_ioctls_supported?
> > 
> > I believe that's what David mentioned very initially here:
> > 
> > https://lore.kernel.org/r/f1da3505-f17f-4829-80c1-696b1d99057d@redhat.com
> > 
> > I'd rather go with the two fields, but if we're trying to introduce another
> > feature sets almost only for vm_uffd_ops, I'd prefer keeping it simple, and
> > deduce the modes from ioctls.
> > 
> > Is that ok for you?  So it'll have (1) get_folio(), (2) supported_ioctls.
> > That's all.
> 
> This is still middleware - a translation of flags passed in to figure
> out what function to call.  I don't think this is the best path forward
> as it means we have to complicate the layer for every user we add while
> we are already providing the most flexible return of a folio.
> 
> This will end up making things worse, IMO.
> 
> Think, for example, we add hugetlbfs_v2 - every place we have
> "if (is_hugetlbfs())" will now need an "else if(is_hugetlbfsv2())" to
> accommodate something that probably has the same uffd_ops as hugetlbfs
> v1.
> 
> Why would we do this instead of actually making your uffd_ops a complete
> API, or at least a subset of the API that supports guest-memfd?

It will be the complete API with (1) and (2) on minor fault.

When one proposes hugetlbfsv2, it should make sure it will work with the
API that only has (1)+(2).  Some uffd paths may need touch up (e.g. on
detecting VMA sizes), but it'll never be "if (is_hugetlbfsv2())".

That's IMHO one of the major purposes of having hugetlbfsv2 after all,
which is to start using the common MM apis, including the one we're going
to introduce here.

Thanks,

-- 
Peter Xu