[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aN08NxRLz7Wx0Qh4@x1.local>
Date: Wed, 1 Oct 2025 10:35:35 -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 Wed, Oct 01, 2025 at 03:58:14PM +0200, David Hildenbrand wrote:
> > > > > 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.
> >
>
> Just wondering, is this confusing to you, and if so, which part?
>
> To me it makes perfect sense and cleans up this API and not have to sets of
> flags that are somehow interlinked.
It adds the extra layer of mapping that will only be used in vm_uffd_ops
and the helper that will consume it.
But I confess this might be subjective.
>
> > > >
> > > > 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..
>
> Do you know what the plans are with guest_memfd?
I am not aware of anyone discussing this yet, but IMHO we need to support
it at least for the !CoCo use cases.
I do not know how CoCo manages poisoned pages, e.g. if they are kept being
encrypted or not even if corrupted.
Thanks,
--
Peter Xu
Powered by blists - more mailing lists