From: Peter Xu <peterx@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
Axel Rasmussen <axelrasmussen@google.com>,
Vlastimil Babka <vbabka@suse.cz>,
James Houghton <jthoughton@google.com>,
Nikita Kalyazin <kalyazin@amazon.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Ujwal Kundur <ujwal.kundur@gmail.com>,
Mike Rapoport <rppt@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andrea Arcangeli <aarcange@redhat.com>,
"Liam R . Howlett" <Liam.Howlett@oracle.com>,
Michal Hocko <mhocko@suse.com>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Hugh Dickins <hughd@google.com>,
Suren Baghdasaryan <surenb@google.com>
Subject: Re: [PATCH v3 4/4] mm: Apply vm_uffd_ops API to core mm
Date: Tue, 30 Sep 2025 14:52:42 -0400 [thread overview]
Message-ID: <aNwm-uAt98KA9Euh@x1.local> (raw)
In-Reply-To: <0a60d99b-fa3b-482b-8171-ac63dcdf3168@redhat.com>
On Tue, Sep 30, 2025 at 11:23:19AM +0200, David Hildenbrand wrote:
> On 26.09.25 23:16, Peter Xu wrote:
> > Move userfaultfd core to use new vm_uffd_ops API. After this change file
> > systems that implement vm_operations_struct can start using new API for
> > userfaultfd operations.
> >
> > When at it, moving vma_can_userfault() into mm/userfaultfd.c instead,
> > because it's getting too big. It's only used in slow paths so it shouldn't
> > be an issue. Move the pte marker check before wp_async, which might be
> > more intuitive because wp_async depends on pte markers. That shouldn't
> > cause any functional change though because only one check would take effect
> > depending on whether pte marker was selected in config.
> >
> > This will also remove quite some hard-coded checks for either shmem or
> > hugetlbfs. Now all the old checks should still work but with vm_uffd_ops.
> >
> > Note that anonymous memory will still need to be processed separately
> > because it doesn't have vm_ops at all.
> >
> > Reviewed-by: James Houghton <jthoughton@google.com>
> > Acked-by: Mike Rapoport <rppt@kernel.org>
> > Signed-off-by: Peter Xu <peterx@redhat.com>
> > ---
>
> [...]
>
> > +++ b/mm/userfaultfd.c
> > @@ -20,6 +20,43 @@
> > #include "internal.h"
> > #include "swap.h"
> > +bool vma_can_userfault(struct vm_area_struct *vma, vm_flags_t vm_flags,
> > + bool wp_async)
> > +{
> > + unsigned long supported;
> > +
> > + if (vma->vm_flags & VM_DROPPABLE)
> > + return false;
> > +
> > + vm_flags &= __VM_UFFD_FLAGS;
> > +
> > +#ifndef CONFIG_PTE_MARKER_UFFD_WP
>
> While at it, you can turn that into an
> !IS_ENABLED(CONFIG_PTE_MARKER_UFFD_WP) to avoid the ifdef.
>
> > + /*
> > + * If user requested uffd-wp but not enabled pte markers for
> > + * uffd-wp, then any file system (like shmem or hugetlbfs) are not
> > + * supported but only anonymous.
> > + */
> > + if ((vm_flags & VM_UFFD_WP) && !vma_is_anonymous(vma))
> > + return false;
> > +#endif
> > + /*
> > + * If wp async enabled, and WP is the only mode enabled, allow any
> > + * memory type.
> > + */
> > + if (wp_async && (vm_flags == VM_UFFD_WP))
> > + return true;
>
>
> > +
> > + if (vma_is_anonymous(vma))
> > + /* Anonymous has no page cache, MINOR not supported */
> > + supported = VM_UFFD_MISSING | VM_UFFD_WP;
> > + else if (vma_get_uffd_ops(vma))
> > + supported = vma_get_uffd_ops(vma)->uffd_features;
> > + else
> > + return false;
>
> To avoid the hidde return here, I think you can just do
>
> supported = 0;
>
>
> Or even cleaner, just do
>
> unsigned long supported = 0
> ...
> if (vma_is_anonymous(vma))
> supported = ...
> else if (vma_get_uffd_ops(vma))
> supported = ...
> return ...
>
> > +
> > + return !(vm_flags & (~supported));
>
> I think this can just be:
>
> return !(vm_flags & ~supported);
Sure thing, I'll apply everything you mentioned above.
Thanks,
--
Peter Xu
next prev parent reply other threads:[~2025-09-30 18:52 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-26 21:16 [PATCH v3 0/4] mm/userfaultfd: modulize memory types Peter Xu
2025-09-26 21:16 ` [PATCH v3 1/4] mm: Introduce vm_uffd_ops API Peter Xu
2025-09-30 9:36 ` David Hildenbrand
2025-09-30 10:07 ` Mike Rapoport
2025-09-30 10:18 ` David Hildenbrand
2025-09-30 18:39 ` Peter Xu
2025-09-30 18:48 ` Peter Xu
2025-09-30 19:19 ` David Hildenbrand
2025-09-30 20:35 ` Peter Xu
2025-10-01 13:58 ` David Hildenbrand
2025-10-01 14:35 ` Peter Xu
2025-10-01 14:39 ` David Hildenbrand
2025-10-03 14:02 ` Peter Xu
2025-10-06 13:38 ` David Hildenbrand
2025-10-06 19:06 ` Liam R. Howlett
2025-10-06 21:02 ` Peter Xu
2025-10-07 3:31 ` Liam R. Howlett
2025-10-07 13:51 ` Peter Xu
2025-10-07 16:03 ` Liam R. Howlett
2025-10-07 16:14 ` David Hildenbrand
2025-10-07 16:47 ` Peter Xu
2025-10-07 18:46 ` Liam R. Howlett
2025-10-07 19:41 ` Peter Xu
2025-10-07 20:23 ` David Hildenbrand
2025-10-07 20:25 ` Liam R. Howlett
2025-10-07 20:40 ` Peter Xu
2025-09-26 21:16 ` [PATCH v3 2/4] mm/shmem: Support " Peter Xu
2025-09-26 21:16 ` [PATCH v3 3/4] mm/hugetlb: " Peter Xu
2025-09-26 21:16 ` [PATCH v3 4/4] mm: Apply vm_uffd_ops API to core mm Peter Xu
2025-09-30 9:23 ` David Hildenbrand
2025-09-30 18:52 ` Peter Xu [this message]
2025-09-30 19:49 ` [PATCH v3 0/4] mm/userfaultfd: modulize memory types Liam R. Howlett
2025-09-30 20:45 ` Peter Xu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aNwm-uAt98KA9Euh@x1.local \
--to=peterx@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=david@redhat.com \
--cc=hughd@google.com \
--cc=jthoughton@google.com \
--cc=kalyazin@amazon.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=ujwal.kundur@gmail.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.