All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 David Hildenbrand <david@kernel.org>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	 Barry Song <baohua@kernel.org>, Dev Jain <dev.jain@arm.com>,
	Hugh Dickins <hughd@google.com>,  Jann Horn <jannh@google.com>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	 John Hubbard <jhubbard@nvidia.com>,
	Jonathan Corbet <corbet@lwn.net>,
	 Lance Yang <lance.yang@linux.dev>,
	"Liam R. Howlett" <liam@infradead.org>,
	 Masami Hiramatsu <mhiramat@kernel.org>,
	Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
	 Michal Hocko <mhocko@suse.com>,
	Muchun Song <muchun.song@linux.dev>,
	 Nico Pache <nico.pache@linux.dev>,
	Oscar Salvador <osalvador@suse.de>,
	 Pedro Falcato <pfalcato@suse.de>, Peter Xu <peterx@redhat.com>,
	 Ryan Roberts <ryan.roberts@arm.com>,
	Shakeel Butt <shakeel.butt@linux.dev>,
	 Shuah Khan <skhan@linuxfoundation.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	 Suren Baghdasaryan <surenb@google.com>,
	Usama Arif <usama.arif@linux.dev>,
	 Vlastimil Babka <vbabka@kernel.org>, Zi Yan <ziy@nvidia.com>,
	linux-doc@vger.kernel.org,  linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	 linux-trace-kernel@vger.kernel.org
Subject: Re: [PATCH 1/6] mm/gup: move gup_can_follow_protnone() to gup.c
Date: Mon, 24 Aug 2026 15:59:26 +0100	[thread overview]
Message-ID: <aoxcRstdSy99lNEA@gremlin> (raw)
In-Reply-To: <20260823-uffd-vm-flags-v1-v1-1-3086981b33cf@kernel.org>

On Sun, Aug 23, 2026 at 03:17:38PM +0300, Mike Rapoport (Microsoft) wrote:
> gup_can_follow_protnone() is defined in include/linux/mm.h but only used
> by mm/gup.c.
>
> First, there is no reason to have it in already gigantic header.
>
> Next, the upcoming refactoring of userfaultfd flags will make
> gup_can_follow_protnone() depend on userfaultfd_k.h which would cause a
> cyclic header dependency.
>
> Move gup_can_follow_protnone() to mm/gup.c.
>
> No functional change.
>
> Assisted-by: copilot:claude-opus-5
> Signed-off-by: Mike Rapoport (Microsoft) <rppt@kernel.org>

LGTM so:

Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>

> ---
>  include/linux/mm.h | 38 --------------------------------------
>  mm/gup.c           | 38 ++++++++++++++++++++++++++++++++++++++
>  2 files changed, 38 insertions(+), 38 deletions(-)
>
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index 0829e0d3b2d1..4daf9cd6ae8e 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
> @@ -4860,44 +4860,6 @@ static inline int vm_fault_to_errno(vm_fault_t vm_fault, int foll_flags)
>  	return 0;
>  }
>
> -/*
> - * Indicates whether GUP can follow a PROT_NONE mapped page, or whether
> - * a (NUMA hinting or userfaultfd RWP) fault is required.
> - */
> -static inline bool gup_can_follow_protnone(const struct vm_area_struct *vma,
> -					   unsigned int flags)
> -{
> -	/*
> -	 * VM_UFFD_RWP uses protnone as an access-tracking marker, not for
> -	 * NUMA hinting. GUP must always take a fault so the access is
> -	 * delivered to userfaultfd, regardless of FOLL_HONOR_NUMA_FAULT.
> -	 *
> -	 * Only do so while the VMA is accessible. If it has been made
> -	 * inaccessible (e.g. mprotect(PROT_NONE)), fall through to the guard
> -	 * below: forcing a fault there would loop, as handle_mm_fault() makes
> -	 * no progress on protnone in an inaccessible VMA, and the access is
> -	 * denied regardless of RWP anyway.
> -	 */
> -	if (vma_test_single_mask(vma, VMA_UFFD_RWP) && vma_is_accessible(vma))
> -		return false;
> -
> -	/*
> -	 * If callers don't want to honor NUMA hinting faults, no need to
> -	 * determine if we would actually have to trigger a NUMA hinting fault.
> -	 */
> -	if (!(flags & FOLL_HONOR_NUMA_FAULT))
> -		return true;
> -
> -	/*
> -	 * NUMA hinting faults don't apply in inaccessible (PROT_NONE) VMAs.
> -	 *
> -	 * Requiring a fault here even for inaccessible VMAs would mean that
> -	 * FOLL_FORCE cannot make any progress, because handle_mm_fault()
> -	 * refuses to process NUMA hinting faults in inaccessible VMAs.
> -	 */
> -	return !vma_is_accessible(vma);
> -}
> -
>  typedef int (*pte_fn_t)(pte_t *pte, unsigned long addr, void *data);
>  extern int apply_to_page_range(struct mm_struct *mm, unsigned long address,
>  			       unsigned long size, pte_fn_t fn, void *data);
> diff --git a/mm/gup.c b/mm/gup.c
> index eb898ea1ee22..500e2aa99e48 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -633,6 +633,44 @@ static struct page *no_page_table(struct vm_area_struct *vma,
>  	return NULL;
>  }
>
> +/*
> + * Indicates whether GUP can follow a PROT_NONE mapped page, or whether
> + * a (NUMA hinting or userfaultfd RWP) fault is required.
> + */
> +static inline bool gup_can_follow_protnone(const struct vm_area_struct *vma,
> +					   unsigned int flags)
> +{
> +	/*
> +	 * VM_UFFD_RWP uses protnone as an access-tracking marker, not for
> +	 * NUMA hinting. GUP must always take a fault so the access is
> +	 * delivered to userfaultfd, regardless of FOLL_HONOR_NUMA_FAULT.
> +	 *
> +	 * Only do so while the VMA is accessible. If it has been made
> +	 * inaccessible (e.g. mprotect(PROT_NONE)), fall through to the guard
> +	 * below: forcing a fault there would loop, as handle_mm_fault() makes
> +	 * no progress on protnone in an inaccessible VMA, and the access is
> +	 * denied regardless of RWP anyway.
> +	 */
> +	if (vma_test_single_mask(vma, VMA_UFFD_RWP) && vma_is_accessible(vma))
> +		return false;
> +
> +	/*
> +	 * If callers don't want to honor NUMA hinting faults, no need to
> +	 * determine if we would actually have to trigger a NUMA hinting fault.
> +	 */
> +	if (!(flags & FOLL_HONOR_NUMA_FAULT))
> +		return true;
> +
> +	/*
> +	 * NUMA hinting faults don't apply in inaccessible (PROT_NONE) VMAs.
> +	 *
> +	 * Requiring a fault here even for inaccessible VMAs would mean that
> +	 * FOLL_FORCE cannot make any progress, because handle_mm_fault()
> +	 * refuses to process NUMA hinting faults in inaccessible VMAs.
> +	 */
> +	return !vma_is_accessible(vma);
> +}
> +
>  #ifdef CONFIG_PGTABLE_HAS_HUGE_LEAVES
>  /* FOLL_FORCE can write to even unwritable PUDs in COW mappings. */
>  static inline bool can_follow_write_pud(pud_t pud, struct page *page,
>
> --
> 2.53.0
>

--
Cheers, Lorenzo


  parent reply	other threads:[~2026-08-24 14:59 UTC|newest]

Thread overview: 49+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-23 12:17 [PATCH 0/6] userfaultfd: decouple uffd mode from VMA flags Mike Rapoport (Microsoft)
2026-08-23 12:17 ` [PATCH 1/6] mm/gup: move gup_can_follow_protnone() to gup.c Mike Rapoport (Microsoft)
2026-08-23 21:03   ` Barry Song
2026-08-24 14:42   ` David Hildenbrand (Arm)
2026-08-25 10:10     ` Mike Rapoport
2026-08-24 14:59   ` Lorenzo Stoakes (ARM) [this message]
2026-08-25  2:03   ` Zi Yan
2026-08-23 12:17 ` [PATCH 2/6] userfaultfd: constify VMA parameter of userfaultfd_*() helpers Mike Rapoport (Microsoft)
2026-08-23 12:27   ` sashiko-bot
2026-08-23 21:03   ` Barry Song
2026-08-24 15:03   ` Lorenzo Stoakes (ARM)
2026-08-25  2:03   ` Zi Yan
2026-08-23 12:17 ` [PATCH 3/6] userfaultfd: use userfaultfd_*() helpers instead of open coded flag tests Mike Rapoport (Microsoft)
2026-08-23 21:14   ` Barry Song
2026-08-24 15:10   ` Lorenzo Stoakes (ARM)
2026-08-25 11:19     ` Mike Rapoport
2026-08-25 11:26       ` Lorenzo Stoakes (ARM)
2026-08-27  7:14         ` Mike Rapoport
2026-08-23 12:17 ` [PATCH 4/6] userfaultfd: rename vm_userfaultfd_ctx to vm_uffd_state Mike Rapoport (Microsoft)
2026-08-24 14:43   ` David Hildenbrand (Arm)
2026-08-24 15:42   ` Lorenzo Stoakes (ARM)
2026-08-23 12:17 ` [PATCH 5/6] userfaultfd: decouple fault reason from VMA flags Mike Rapoport (Microsoft)
2026-08-24  8:12   ` Muchun Song
2026-08-24 14:46   ` David Hildenbrand (Arm)
2026-08-27  7:49     ` Mike Rapoport
2026-08-27  8:10       ` David Hildenbrand (Arm)
2026-08-27  9:09         ` Mike Rapoport
2026-08-27  9:19           ` David Hildenbrand (Arm)
2026-08-27  9:21             ` Lorenzo Stoakes (ARM)
2026-08-24 16:28   ` Lorenzo Stoakes (ARM)
2026-08-25 10:37     ` Mike Rapoport
2026-08-25 11:08       ` David Hildenbrand (Arm)
2026-08-25 11:38         ` Lorenzo Stoakes (ARM)
2026-08-25 13:00       ` Lorenzo Stoakes (ARM)
2026-08-27  7:42         ` Mike Rapoport
2026-08-27 11:29           ` Lorenzo Stoakes (ARM)
2026-08-23 12:17 ` [PATCH 6/6] userfaultfd: collapse VM_UFFD_{MISSING,WP,MINOR,RWP} into single VM_UFFD Mike Rapoport (Microsoft)
2026-08-24  7:11   ` Lance Yang
2026-08-24  8:17     ` Mike Rapoport
2026-08-24  8:27       ` Lance Yang
2026-08-25 12:44   ` Lorenzo Stoakes (ARM)
2026-08-25 12:45     ` Lorenzo Stoakes (ARM)
2026-08-27  9:03     ` Mike Rapoport
2026-08-27 11:16       ` Lorenzo Stoakes (ARM)
2026-08-27 11:18         ` Lorenzo Stoakes (ARM)
2026-08-27 15:19           ` David Hildenbrand (Arm)
2026-08-29 11:00             ` Mike Rapoport
2026-08-29 18:42               ` Tal Zussman
2026-08-30  5:36                 ` Mike Rapoport

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=aoxcRstdSy99lNEA@gremlin \
    --to=ljs@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=baohua@kernel.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=dev.jain@arm.com \
    --cc=hughd@google.com \
    --cc=jannh@google.com \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=lance.yang@linux.dev \
    --cc=liam@infradead.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-trace-kernel@vger.kernel.org \
    --cc=mathieu.desnoyers@efficios.com \
    --cc=mhiramat@kernel.org \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=nico.pache@linux.dev \
    --cc=osalvador@suse.de \
    --cc=peterx@redhat.com \
    --cc=pfalcato@suse.de \
    --cc=rostedt@goodmis.org \
    --cc=rppt@kernel.org \
    --cc=ryan.roberts@arm.com \
    --cc=shakeel.butt@linux.dev \
    --cc=skhan@linuxfoundation.org \
    --cc=surenb@google.com \
    --cc=usama.arif@linux.dev \
    --cc=vbabka@kernel.org \
    --cc=ziy@nvidia.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 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.