From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Dev Jain <dev.jain@arm.com>,
akpm@linux-foundation.org, ljs@kernel.org, chrisl@kernel.org,
kasong@tencent.com, hughd@google.com, liam@infradead.org
Cc: riel@surriel.com, vbabka@kernel.org, harry@kernel.org,
jannh@google.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, qi.zheng@linux.dev, shakeel.butt@linux.dev,
baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com,
weixugc@google.com, shikemeng@huaweicloud.com, nphamcs@gmail.com,
bhe@redhat.com, youngjun.park@lge.com,
baolin.wang@linux.alibaba.com, pfalcato@suse.de,
ryan.roberts@arm.com, anshuman.khandual@arm.com
Subject: Re: [PATCH v4 04/12] mm/memory: Batch set uffd-wp markers during zapping
Date: Tue, 16 Jun 2026 15:43:18 +0200 [thread overview]
Message-ID: <a9483db7-5b13-40ff-8d45-12f40dc97c77@kernel.org> (raw)
In-Reply-To: <20260526063635.61721-5-dev.jain@arm.com>
On 5/26/26 08:36, Dev Jain wrote:
> In preparation for the next patch, enable batch setting of uffd-wp ptes.
Avoid talking about "next patch". Phrase it as "In preparation for batching...".
>
> The code paths passing nr > 1 to zap_install_uffd_wp_if_needed() produce
> that nr through either folio_pte_batch or swap_pte_batch, therefore
> batching is correct:
>
> 1) all ptes belong to the same type of VMA (anonymous or non-anonymous,
> wp-armed or non-wp-armed)
>
> 2) all ptes being marked with uffd-wp or all being not marked (same is the
> case with the pte_swp_uffd_wp_any check)
>
> 3) uffd_supports_wp_marker() is independent of the function parameters
>
> Note that we will have to use set_pte_at() in a loop instead of set_ptes()
> since the latter cannot handle present->non-present conversion for
> nr_pages > 1.
Below you have
> + /* The current status of the pte should be "cleared" before calling */
> + WARN_ON_ONCE(!pte_none(ptep_get(ptep)));
Could we easily extend set_ptes() to allow for non-present -> non-present with
nr > 1?
>
> Rename the function to cond_install_uffd_wp_ptes, and convert the
> documentation to kerneldoc format.
>
> Move the function to memory.c since this has grown too long to be kept
> in mm_inline.h, while retaining the inline hint.
Well, for functions in the header you really need "static inline", so it's not a
hint and I would just drop that comment.
However, the move while modifying a larger function is rather suboptimal for
reviewing (more like "spot the difference between these two pictures"). I'd
suggest moving it in one patch, and thenb modifying it in a second (this) patch
instead. You can perform the rename already while moving I think.
Nothing else jumped at me.
--
Cheers,
David
next prev parent reply other threads:[~2026-06-16 13:43 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-26 6:36 [PATCH v4 00/12] Optimize anonymous large folio unmapping Dev Jain
2026-05-26 6:36 ` [PATCH v4 01/12] mm/rmap: convert page -> folio for hwpoison checks Dev Jain
2026-06-09 13:44 ` David Hildenbrand (Arm)
2026-06-10 7:02 ` Dev Jain
2026-06-10 12:13 ` David Hildenbrand (Arm)
2026-05-26 6:36 ` [PATCH v4 02/12] mm/rmap: Add try_to_unmap_hugetlb_one Dev Jain
2026-06-09 14:16 ` David Hildenbrand (Arm)
2026-05-26 6:36 ` [PATCH v4 03/12] mm/rmap: refactor some code around lazyfree folio unmapping Dev Jain
2026-06-09 14:20 ` David Hildenbrand (Arm)
2026-05-26 6:36 ` [PATCH v4 04/12] mm/memory: Batch set uffd-wp markers during zapping Dev Jain
2026-06-16 13:43 ` David Hildenbrand (Arm) [this message]
2026-05-26 6:36 ` [PATCH v4 05/12] mm/rmap: batch unmap folios belonging to uffd-wp VMAs Dev Jain
2026-05-26 6:36 ` [PATCH v4 06/12] mm/swap: rename subpage->page in folio_dup_swap/folio_put_swap Dev Jain
2026-06-16 13:47 ` David Hildenbrand (Arm)
2026-05-26 6:36 ` [PATCH v4 07/12] mm/swapfile: Add batched version of folio_dup_swap Dev Jain
2026-06-16 13:50 ` David Hildenbrand (Arm)
2026-06-16 13:51 ` David Hildenbrand (Arm)
2026-05-26 6:36 ` [PATCH v4 08/12] mm/swapfile: Add batched version of folio_put_swap Dev Jain
2026-06-16 13:54 ` David Hildenbrand (Arm)
2026-05-26 6:36 ` [PATCH v4 09/12] mm/rmap: Add batched version of folio_try_share_anon_rmap_pte Dev Jain
2026-06-16 14:04 ` David Hildenbrand (Arm)
2026-05-26 6:36 ` [PATCH v4 10/12] mm/rmap: refactor anon folio unmap in try_to_unmap_one Dev Jain
2026-06-16 14:10 ` David Hildenbrand (Arm)
2026-05-26 6:36 ` [PATCH v4 11/12] mm/mprotect: drop 'sub' from page_anon_exclusive_sub_batch Dev Jain
2026-06-16 14:12 ` David Hildenbrand (Arm)
2026-05-26 6:36 ` [PATCH v4 12/12] mm/rmap: enable batch unmapping of anonymous folios Dev Jain
2026-05-28 16:50 ` [PATCH v4 00/12] Optimize anonymous large folio unmapping Dev Jain
2026-06-09 13:24 ` David Hildenbrand (Arm)
2026-06-09 14:18 ` 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=a9483db7-5b13-40ff-8d45-12f40dc97c77@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=anshuman.khandual@arm.com \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=bhe@redhat.com \
--cc=chrisl@kernel.org \
--cc=dev.jain@arm.com \
--cc=harry@kernel.org \
--cc=hughd@google.com \
--cc=jannh@google.com \
--cc=kasong@tencent.com \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=nphamcs@gmail.com \
--cc=pfalcato@suse.de \
--cc=qi.zheng@linux.dev \
--cc=riel@surriel.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=shakeel.butt@linux.dev \
--cc=shikemeng@huaweicloud.com \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=weixugc@google.com \
--cc=youngjun.park@lge.com \
--cc=yuanchu@google.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.