linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Nikita Kalyazin <kalyazin@amazon.com>
Cc: akpm@linux-foundation.org, pbonzini@redhat.com, shuah@kernel.org,
	viro@zeniv.linux.org.uk, brauner@kernel.org,
	muchun.song@linux.dev, hughd@google.com, kvm@vger.kernel.org,
	linux-kselftest@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, jack@suse.cz,
	lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
	jannh@google.com, ryan.roberts@arm.com, david@redhat.com,
	jthoughton@google.com, graf@amazon.de, jgowans@amazon.com,
	roypat@amazon.co.uk, derekmn@amazon.com, nsaenz@amazon.es,
	xmarcalx@amazon.com
Subject: Re: [PATCH v3 1/6] mm: userfaultfd: generic continue for non hugetlbfs
Date: Tue, 10 Jun 2025 18:22:22 -0400	[thread overview]
Message-ID: <aEiwHjl4tsUt98sh@x1.local> (raw)
In-Reply-To: <20250404154352.23078-2-kalyazin@amazon.com>

On Fri, Apr 04, 2025 at 03:43:47PM +0000, Nikita Kalyazin wrote:
> Remove shmem-specific code from UFFDIO_CONTINUE implementation for
> non-huge pages by calling vm_ops->fault().  A new VMF flag,
> FAULT_FLAG_USERFAULT_CONTINUE, is introduced to avoid recursive call to
> handle_userfault().

It's not clear yet on why this is needed to be generalized out of the blue.

Some mentioning of guest_memfd use case might help for other reviewers, or
some mention of the need to introduce userfaultfd support in kernel
modules.

> 
> Suggested-by: James Houghton <jthoughton@google.com>
> Signed-off-by: Nikita Kalyazin <kalyazin@amazon.com>
> ---
>  include/linux/mm_types.h |  4 ++++
>  mm/hugetlb.c             |  2 +-
>  mm/shmem.c               |  9 ++++++---
>  mm/userfaultfd.c         | 37 +++++++++++++++++++++++++++----------
>  4 files changed, 38 insertions(+), 14 deletions(-)
> 
> diff --git a/include/linux/mm_types.h b/include/linux/mm_types.h
> index 0234f14f2aa6..2f26ee9742bf 100644
> --- a/include/linux/mm_types.h
> +++ b/include/linux/mm_types.h
> @@ -1429,6 +1429,9 @@ enum tlb_flush_reason {
>   * @FAULT_FLAG_ORIG_PTE_VALID: whether the fault has vmf->orig_pte cached.
>   *                        We should only access orig_pte if this flag set.
>   * @FAULT_FLAG_VMA_LOCK: The fault is handled under VMA lock.
> + * @FAULT_FLAG_USERFAULT_CONTINUE: The fault handler must not call userfaultfd
> + *                                 minor handler as it is being called by the
> + *                                 userfaultfd code itself.

We probably shouldn't leak the "CONTINUE" concept to mm core if possible,
as it's not easy to follow when without userfault minor context.  It might
be better to use generic terms like NO_USERFAULT.

Said that, I wonder if we'll need to add a vm_ops anyway in the latter
patch, whether we can also avoid reusing fault() but instead resolve the
page faults using the vm_ops hook too.  That might be helpful because then
we can avoid this new FAULT_FLAG_* that is totally not useful to
non-userfault users, meanwhile we also don't need to hand-cook the vm_fault
struct below just to suite the current fault() interfacing.

Thanks,

-- 
Peter Xu


  reply	other threads:[~2025-06-10 22:22 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-04 15:43 [PATCH v3 0/6] KVM: guest_memfd: support for uffd minor Nikita Kalyazin
2025-04-04 15:43 ` [PATCH v3 1/6] mm: userfaultfd: generic continue for non hugetlbfs Nikita Kalyazin
2025-06-10 22:22   ` Peter Xu [this message]
2025-06-11 12:09     ` Nikita Kalyazin
2025-06-11 12:56       ` Peter Xu
2025-06-20 12:00         ` Nikita Kalyazin
2025-06-20 15:21           ` Peter Xu
2025-06-20 16:51             ` Nikita Kalyazin
2025-04-04 15:43 ` [PATCH v3 2/6] mm: provide can_userfault vma operation Nikita Kalyazin
2025-04-04 15:43 ` [PATCH v3 3/6] mm: userfaultfd: use " Nikita Kalyazin
2025-04-04 15:43 ` [PATCH v3 4/6] KVM: guest_memfd: add support for userfaultfd minor Nikita Kalyazin
2025-06-10 22:25   ` Peter Xu
2025-06-11 12:09     ` Nikita Kalyazin
2025-04-04 15:43 ` [PATCH v3 5/6] mm: userfaultfd: add UFFD_FEATURE_MINOR_GUEST_MEMFD Nikita Kalyazin
2025-04-04 15:43 ` [PATCH v3 6/6] KVM: selftests: test userfaultfd minor for guest_memfd Nikita Kalyazin
2025-04-04 16:33 ` [PATCH v3 0/6] KVM: guest_memfd: support for uffd minor Lorenzo Stoakes
2025-04-04 16:56   ` Nikita Kalyazin
2025-04-04 16:59     ` Lorenzo Stoakes
2025-04-04 17:12 ` Liam R. Howlett
2025-04-07 11:04   ` Nikita Kalyazin
2025-04-07 13:40     ` Liam R. Howlett
2025-04-07 14:04       ` Nikita Kalyazin
2025-04-07 14:24         ` Liam R. Howlett
2025-04-07 14:46           ` David Hildenbrand
2025-04-07 15:14             ` Lorenzo Stoakes
2025-04-07 15:26               ` David Hildenbrand
2025-04-08  8:20             ` Christian Brauner
2025-04-08 13:15               ` Ackerley Tng

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=aEiwHjl4tsUt98sh@x1.local \
    --to=peterx@redhat.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=brauner@kernel.org \
    --cc=david@redhat.com \
    --cc=derekmn@amazon.com \
    --cc=graf@amazon.de \
    --cc=hughd@google.com \
    --cc=jack@suse.cz \
    --cc=jannh@google.com \
    --cc=jgowans@amazon.com \
    --cc=jthoughton@google.com \
    --cc=kalyazin@amazon.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=muchun.song@linux.dev \
    --cc=nsaenz@amazon.es \
    --cc=pbonzini@redhat.com \
    --cc=roypat@amazon.co.uk \
    --cc=ryan.roberts@arm.com \
    --cc=shuah@kernel.org \
    --cc=viro@zeniv.linux.org.uk \
    --cc=xmarcalx@amazon.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).