[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aNw_GrZsql_M04T0@x1.local>
Date: Tue, 30 Sep 2025 16:35:38 -0400
From: Peter Xu <peterx@...hat.com>
To: David Hildenbrand <david@...hat.com>
Cc: linux-mm@...ck.org, linux-kernel@...r.kernel.org,
Axel Rasmussen <axelrasmussen@...gle.com>,
Vlastimil Babka <vbabka@...e.cz>,
James Houghton <jthoughton@...gle.com>,
Nikita Kalyazin <kalyazin@...zon.com>,
Lorenzo Stoakes <lorenzo.stoakes@...cle.com>,
Ujwal Kundur <ujwal.kundur@...il.com>,
Mike Rapoport <rppt@...nel.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Andrea Arcangeli <aarcange@...hat.com>,
"Liam R . Howlett" <Liam.Howlett@...cle.com>,
Michal Hocko <mhocko@...e.com>, Muchun Song <muchun.song@...ux.dev>,
Oscar Salvador <osalvador@...e.de>, Hugh Dickins <hughd@...gle.com>,
Suren Baghdasaryan <surenb@...gle.com>
Subject: Re: [PATCH v3 1/4] mm: Introduce vm_uffd_ops API
On Tue, Sep 30, 2025 at 09:19:05PM +0200, David Hildenbrand wrote:
> On 30.09.25 20:48, Peter Xu wrote:
> > On Tue, Sep 30, 2025 at 11:36:53AM +0200, David Hildenbrand wrote:
> > > > +/* VMA userfaultfd operations */
> > > > +struct vm_uffd_ops {
> > > > + /**
> > > > + * @uffd_features: features supported in bitmask.
> > > > + *
> > > > + * When the ops is defined, the driver must set non-zero features
> > > > + * to be a subset (or all) of: VM_UFFD_MISSING|WP|MINOR.
> > > > + *
> > > > + * NOTE: VM_UFFD_MISSING is still only supported under mm/ so far.
> > > > + */
> > > > + unsigned long uffd_features;
> > >
> > > This variable name is a bit confusing , because it's all about vma flags,
> > > not uffd features. Just reading the variable, I would rather connect it to
> > > things like UFFD_FEATURE_WP_UNPOPULATED.
> > >
> > > As currently used for VM flags, maybe you should call this
> > >
> > > unsigned long uffd_vm_flags;
> > >
> > > or sth like that.
> >
> > Indeed it's slightly confusing. However uffd_vm_flags is confusing in
> > another way, where it seems to imply some flags similar to vm_flags that is
> > prone to change.
> >
> > How about uffd_vm_flags_supported / uffd_modes_supported?
>
> The former would make things clearer when we are at least not talking about
> uffd features.
I'll go with it.
>
> >
> > >
> > > I briefly wondered whether we could use actual UFFD_FEATURE_* here, but they
> > > are rather unsuited for this case here (e.g., different feature flags for
> > > hugetlb support/shmem support etc).
> > >
> > > But reading "uffd_ioctls" below, can't we derive the suitable vma flags from
> > > the supported ioctls?
> > >
> > > _UFFDIO_COPY | _UFDIO_ZEROPAGE -> VM_UFFD_MISSING
> > > _UFFDIO_WRITEPROTECT -> VM_UFFD_WP
> > > _UFFDIO_CONTINUE -> VM_UFFD_MINOR
> >
> > Yes we can deduce that, but it'll be unclear then when one stares at a
> > bunch of ioctls and cannot easily digest the modes the memory type
> > supports. Here, the modes should be the most straightforward way to
> > describe the capability of a memory type.
>
> I rather dislike the current split approach between vm-flags and ioctls.
>
> I briefly thought about abstracting it for internal purposes further and
> just have some internal backend ("memory type") flags.
>
> UFFD_BACKEND_FEAT_MISSING -> _UFFDIO_COPY and VM_UFFD_MISSING
> UFFD_BACKEND_FEAT_ZEROPAGE -> _UFDIO_ZEROPAGE
> UFFD_BACKEND_FEAT_WP -> _UFFDIO_WRITEPROTECT and VM_UFFD_WP
> UFFD_BACKEND_FEAT_MINOR -> _UFFDIO_CONTINUE and VM_UFFD_MINOR
> UFFD_BACKEND_FEAT_POISON -> _UFFDIO_POISON
This layer of mapping can be helpful to some, but maybe confusing to
others.. who is familiar with existing userfaultfd definitions.
> >
> > If hugetlbfs supported ZEROPAGE, then we can deduce the ioctls the other
> > way round, and we can drop the uffd_ioctls. However we need the ioctls now
> > for hugetlbfs to make everything generic.
>
> POISON is not a VM_ flag, so that wouldn't work completely, right?
Logically speaking, POISON should be meaningful if MISSING|MINOR is
supported. However, in reality, POISON should always be supported across
all types..
>
> As a side note, hugetlbfs support for ZEROPAGE should be fairly easy:
> similar to shmem support, simply allocate a zeroed hugetlb folio.
IMHO it'll be good if we do not introduce ZEROPAGE only because we want to
remove some flags.. We could be introducing dead codes that nobody uses.
I think it'll be good if we put that as a separate discussion, and define
the vm_uffd_ops based on the current situation.
>
> >
> > Do you mind I still keep it as-is?
>
> I would prefer if we find a way to not have this dependency between both
> feature/ioctl thingies. It just looks rather odd.
>
> But let's hear if there are other opinions.
Sure.
--
Peter Xu
Powered by blists - more mailing lists