All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Rik van Riel <riel@surriel.com>, linux-kernel@vger.kernel.org
Cc: kernel-team@meta.com, Andrew Morton <akpm@linux-foundation.org>,
	Jason Gunthorpe <jgg@ziepe.ca>,
	John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
	linux-mm@kvack.org
Subject: Re: [RFC PATCH v3 3/8] mm/gup: split follow_page_pte_commit() out of follow_page_pte()
Date: Wed, 12 Aug 2026 13:50:17 +0200	[thread overview]
Message-ID: <8a9d5a6f-a7c6-468f-8b50-a7aa2b4dea2c@kernel.org> (raw)
In-Reply-To: <20260811025157.1632867-4-riel@surriel.com>

On 8/11/26 04:51, Rik van Riel wrote:
> follow_page_pte() does two things once it has resolved a present PTE
> to a page: run the per-PTE safety checks (write-fault, unshare), then
> commit to that page: grab a ref, fault it in if pinning, mark it
> dirty/accessed, and hand it back to the caller.
> 
> Split the second part into its own follow_page_pte_commit(), unchanged
> except for taking its inputs as parameters instead of local variables,
> so the checks and the commit can be applied at different granularities.
> 
> No functional changes intended.
> 
> Suggested-by: David Hildenbrand <david@kernel.org>
> Assisted-by: Claude:claude-opus-4-8
> Signed-off-by: Rik van Riel <riel@surriel.com>
> ---
>  mm/gup.c | 78 +++++++++++++++++++++++++++++++++++---------------------
>  1 file changed, 49 insertions(+), 29 deletions(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index e4e6d0993424..b755ceaac0f5 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -822,6 +822,52 @@ static inline bool can_follow_write_pte(pte_t pte, struct page *page,
>  	return !userfaultfd_pte_wp(vma, pte);
>  }
>  
> +/*
> + * The caller has already run every per-PTE safety check (present,
> + * write-fault, gup_must_unshare()) on the PTE, so this only does the
> + * per-folio work: the refcount grab, the FOLL_PIN accessibility fault-in,
> + * dirty/accessed marking, and the array fill with the cache flush.
> + */

If a function needs 4 lines of internal doc to understand what it does, then
maybe it's not the right function name or abstraction. :)

I don't particularly enjoy the "commit" terminology, it looses the detail of the
most important thing this function is supposed to to: grab a folio reference.

We're passing in the pte only to do a single pte_dirty(). If the helper is
actually what we want, likely we just just pass in the pte_dirty() directly and
remove all pte leftovers from the helper.

I'd assume that we'd want a function where we can similarly punch in a PMD/PUD
and have it do the same thing as well, instead of special-casing ptes.

Let me think about this some more, I might have to play with the code myself to
understand how this should all be cleaned up.

-- 
Cheers,

David

  reply	other threads:[~2026-08-12 11:50 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-11  2:51 [RFC PATCH v3 0/8] batch lookups in follow_page_mask() Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 1/8] mm/gup: break out gup_fill_pages() helper Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 2/8] mm/gup: convert follow_page_mask() to return a long Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 3/8] mm/gup: split follow_page_pte_commit() out of follow_page_pte() Rik van Riel
2026-08-12 11:50   ` David Hildenbrand (Arm) [this message]
2026-08-12 13:02     ` Rik van Riel
2026-08-12 13:23       ` David Hildenbrand (Arm)
2026-08-12 16:19         ` Rik van Riel
2026-08-21 17:38         ` Rik van Riel
2026-08-21 22:04           ` John Hubbard
2026-08-11  2:51 ` [RFC PATCH v3 4/8] mm/gup: break out follow_one_pte() helper Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 5/8] mm/gup: fill the pages array outside the pud/pmd lock Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 6/8] mm/gup: return a huge page's full count from follow_page_mask() Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 7/8] mm/gup: walk multiple PTEs per follow_page_pte() call Rik van Riel
2026-08-11  2:51 ` [RFC PATCH v3 8/8] mm/gup: batch contiguous same-folio PTEs into one refcount grab Rik van Riel
2026-08-12 11:41 ` [RFC PATCH v3 0/8] batch lookups in follow_page_mask() David Hildenbrand (Arm)

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=8a9d5a6f-a7c6-468f-8b50-a7aa2b4dea2c@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=jgg@ziepe.ca \
    --cc=jhubbard@nvidia.com \
    --cc=kernel-team@meta.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=peterx@redhat.com \
    --cc=riel@surriel.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.