All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: "linux-mm @ kvack . org" <linux-mm@kvack.org>,
	"David Hildenbrand (Arm)" <david@kernel.org>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Lorenzo Stoakes" <lorenzo.stoakes@oracle.com>,
	"Liam R. Howlett" <Liam.Howlett@oracle.com>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"Mike Rapoport" <rppt@kernel.org>,
	"Suren Baghdasaryan" <surenb@google.com>,
	"Michal Hocko" <mhocko@suse.com>, "Jann Horn" <jannh@google.com>,
	"Pedro Falcato" <pfalcato@suse.de>,
	"David Rientjes" <rientjes@google.com>,
	"Shakeel Butt" <shakeel.butt@linux.dev>,
	"Matthew Wilcox (Oracle)" <willy@infradead.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Madhavan Srinivasan" <maddy@linux.ibm.com>,
	"Michael Ellerman" <mpe@ellerman.id.au>,
	"Christian Borntraeger" <borntraeger@linux.ibm.com>,
	"Janosch Frank" <frankja@linux.ibm.com>,
	"Claudio Imbrenda" <imbrenda@linux.ibm.com>,
	"Alexander Gordeev" <agordeev@linux.ibm.com>,
	"Gerald Schaefer" <gerald.schaefer@linux.ibm.com>,
	"Heiko Carstens" <hca@linux.ibm.com>,
	"Vasily Gorbik" <gor@linux.ibm.com>,
	"Jarkko Sakkinen" <jarkko@kernel.org>,
	"Thomas Gleixner" <tglx@kernel.org>,
	"Ingo Molnar" <mingo@redhat.com>,
	"Borislav Petkov" <bp@alien8.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Todd Kjos" <tkjos@android.com>,
	"Christian Brauner" <brauner@kernel.org>,
	"Carlos Llamas" <cmllamas@google.com>,
	"Ian Abbott" <abbotti@mev.co.uk>,
	"H Hartley Sweeten" <hsweeten@visionengravers.com>,
	"Jani Nikula" <jani.nikula@linux.intel.com>,
	"Joonas Lahtinen" <joonas.lahtinen@linux.intel.com>,
	"Rodrigo Vivi" <rodrigo.vivi@intel.com>,
	"Tvrtko Ursulin" <tursulin@ursulin.net>,
	"David Airlie" <airlied@gmail.com>,
	"Simona Vetter" <simona@ffwll.ch>,
	"Jason Gunthorpe" <jgg@ziepe.ca>,
	"Leon Romanovsky" <leon@kernel.org>,
	"Dimitri Sivanich" <dimitri.sivanich@hpe.com>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Alexei Starovoitov" <ast@kernel.org>,
	"Daniel Borkmann" <daniel@iogearbox.net>,
	"Andrii Nakryiko" <andrii@kernel.org>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Arnaldo Carvalho de Melo" <acme@kernel.org>,
	"Namhyung Kim" <namhyung@kernel.org>,
	"Andy Lutomirski" <luto@kernel.org>,
	"Vincenzo Frascino" <vincenzo.frascino@arm.com>,
	"Eric Dumazet" <edumazet@google.com>,
	"Neal Cardwell" <ncardwell@google.com>,
	"David S. Miller" <davem@davemloft.net>,
	"David Ahern" <dsahern@kernel.org>,
	"Jakub Kicinski" <kuba@kernel.org>,
	"Paolo Abeni" <pabeni@redhat.com>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	linuxppc-dev@lists.ozlabs.org, kvm@vger.kernel.org,
	linux-s390@vger.kernel.org, linux-sgx@vger.kernel.org,
	intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org,
	linux-rdma@vger.kernel.org, bpf@vger.kernel.org,
	linux-perf-users@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	netdev@vger.kernel.org, rust-for-linux@vger.kernel.org,
	x86@kernel.org
Subject: [PATCH v1 08/16] mm/memory: move adjusting of address range to unmap_vmas()
Date: Fri, 27 Feb 2026 21:08:39 +0100	[thread overview]
Message-ID: <20260227200848.114019-9-david@kernel.org> (raw)
In-Reply-To: <20260227200848.114019-1-david@kernel.org>

__zap_vma_range() has two callers, whereby
zap_page_range_single_batched() documents that the range must fit into
the VMA range.

So move adjusting the range to unmap_vmas() where it is actually
required and add a safety check in __zap_vma_range() instead. In
unmap_vmas(), we'd never expect to have empty ranges (otherwise, why
have the vma in there in the first place).

__zap_vma_range() will no longer be called with start == end, so
cleanup the function a bit. While at it, simplify the overly long
comment to its core message.

We will no longer call uprobe_munmap() for start == end, which actually
seems to be the right thing to do.

Note that hugetlb_zap_begin()->...->adjust_range_if_pmd_sharing_possible()
cannot result in the range exceeding the vma range.

Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
---
 mm/memory.c | 58 +++++++++++++++++++++--------------------------------
 1 file changed, 23 insertions(+), 35 deletions(-)

diff --git a/mm/memory.c b/mm/memory.c
index f0aaec57a66b..fdcd2abf29c2 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2073,44 +2073,28 @@ static void unmap_page_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
 	tlb_end_vma(tlb, vma);
 }
 
-
-static void __zap_vma_range(struct mmu_gather *tlb,
-		struct vm_area_struct *vma, unsigned long start_addr,
-		unsigned long end_addr, struct zap_details *details)
+static void __zap_vma_range(struct mmu_gather *tlb, struct vm_area_struct *vma,
+		unsigned long start, unsigned long end,
+		struct zap_details *details)
 {
-	unsigned long start = max(vma->vm_start, start_addr);
-	unsigned long end;
-
-	if (start >= vma->vm_end)
-		return;
-	end = min(vma->vm_end, end_addr);
-	if (end <= vma->vm_start)
-		return;
+	VM_WARN_ON_ONCE(start >= end || !range_in_vma(vma, start, end));
 
 	if (vma->vm_file)
 		uprobe_munmap(vma, start, end);
 
-	if (start != end) {
-		if (unlikely(is_vm_hugetlb_page(vma))) {
-			/*
-			 * It is undesirable to test vma->vm_file as it
-			 * should be non-null for valid hugetlb area.
-			 * However, vm_file will be NULL in the error
-			 * cleanup path of mmap_region. When
-			 * hugetlbfs ->mmap method fails,
-			 * mmap_region() nullifies vma->vm_file
-			 * before calling this function to clean up.
-			 * Since no pte has actually been setup, it is
-			 * safe to do nothing in this case.
-			 */
-			if (vma->vm_file) {
-				zap_flags_t zap_flags = details ?
-				    details->zap_flags : 0;
-				__unmap_hugepage_range(tlb, vma, start, end,
-							     NULL, zap_flags);
-			}
-		} else
-			unmap_page_range(tlb, vma, start, end, details);
+	if (unlikely(is_vm_hugetlb_page(vma))) {
+		zap_flags_t zap_flags = details ? details->zap_flags : 0;
+
+		/*
+		 * vm_file will be NULL when we fail early while instantiating
+		 * a new mapping. In this case, no pages were mapped yet and
+		 * there is nothing to do.
+		 */
+		if (!vma->vm_file)
+			return;
+		__unmap_hugepage_range(tlb, vma, start, end, NULL, zap_flags);
+	} else {
+		unmap_page_range(tlb, vma, start, end, details);
 	}
 }
 
@@ -2174,8 +2158,9 @@ void unmap_vmas(struct mmu_gather *tlb, struct unmap_desc *unmap)
 				unmap->vma_start, unmap->vma_end);
 	mmu_notifier_invalidate_range_start(&range);
 	do {
-		unsigned long start = unmap->vma_start;
-		unsigned long end = unmap->vma_end;
+		unsigned long start = max(vma->vm_start, unmap->vma_start);
+		unsigned long end = min(vma->vm_end, unmap->vma_end);
+
 		hugetlb_zap_begin(vma, &start, &end);
 		__zap_vma_range(tlb, vma, start, end, &details);
 		hugetlb_zap_end(vma, &details);
@@ -2204,6 +2189,9 @@ void zap_page_range_single_batched(struct mmu_gather *tlb,
 
 	VM_WARN_ON_ONCE(!tlb || tlb->mm != vma->vm_mm);
 
+	if (unlikely(!size))
+		return;
+
 	mmu_notifier_range_init(&range, MMU_NOTIFY_CLEAR, 0, vma->vm_mm,
 				address, end);
 	hugetlb_zap_begin(vma, &range.start, &range.end);
-- 
2.43.0


  parent reply	other threads:[~2026-02-27 20:11 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-27 20:08 [PATCH v1 00/16] mm: cleanups around unmapping / zapping David Hildenbrand (Arm)
2026-02-27 20:08 ` [PATCH v1 01/16] mm/madvise: drop range checks in madvise_free_single_vma() David Hildenbrand (Arm)
2026-03-06 12:03   ` Lorenzo Stoakes (Oracle)
2026-02-27 20:08 ` [PATCH v1 02/16] mm/memory: remove "zap_details" parameter from zap_page_range_single() David Hildenbrand (Arm)
2026-02-28 12:38   ` Alice Ryhl
2026-03-02  8:18     ` David Hildenbrand (Arm)
2026-03-02 10:01       ` Alice Ryhl
2026-03-02 10:27         ` David Hildenbrand (Arm)
2026-03-02 10:33           ` Alice Ryhl
2026-03-02 15:01             ` David Hildenbrand (Arm)
2026-03-02 15:41               ` Alice Ryhl
2026-03-03 20:49                 ` Miguel Ojeda
2026-03-04  8:47                   ` David Hildenbrand (Arm)
2026-03-06 12:06   ` Lorenzo Stoakes (Oracle)
2026-03-09 16:44   ` Puranjay Mohan
2026-02-27 20:08 ` [PATCH v1 03/16] mm/memory: inline unmap_mapping_range_vma() into unmap_mapping_range_tree() David Hildenbrand (Arm)
2026-03-06 12:07   ` Lorenzo Stoakes (Oracle)
2026-02-27 20:08 ` [PATCH v1 04/16] mm/memory: simplify calculation in unmap_mapping_range_tree() David Hildenbrand (Arm)
2026-03-06 12:12   ` Lorenzo Stoakes (Oracle)
2026-03-11  8:09     ` David Hildenbrand (Arm)
2026-02-27 20:08 ` [PATCH v1 05/16] mm/oom_kill: use MMU_NOTIFY_CLEAR in __oom_reap_task_mm() David Hildenbrand (Arm)
2026-03-06 12:14   ` Lorenzo Stoakes (Oracle)
2026-02-27 20:08 ` [PATCH v1 06/16] mm/oom_kill: factor out zapping of VMA into zap_vma_for_reaping() David Hildenbrand (Arm)
2026-03-06 12:17   ` Lorenzo Stoakes (Oracle)
2026-02-27 20:08 ` [PATCH v1 07/16] mm/memory: rename unmap_single_vma() to __zap_vma_range() David Hildenbrand (Arm)
2026-03-06 12:17   ` Lorenzo Stoakes (Oracle)
2026-02-27 20:08 ` David Hildenbrand (Arm) [this message]
2026-03-06 12:40   ` [PATCH v1 08/16] mm/memory: move adjusting of address range to unmap_vmas() Lorenzo Stoakes (Oracle)
2026-02-27 20:08 ` [PATCH v1 09/16] mm/memory: convert details->even_cows into details->skip_cows David Hildenbrand (Arm)
2026-03-06 12:21   ` Lorenzo Stoakes (Oracle)
2026-03-11  8:28     ` David Hildenbrand (Arm)
2026-02-27 20:08 ` [PATCH v1 10/16] mm/memory: use __zap_vma_range() in zap_vma_for_reaping() David Hildenbrand (Arm)
2026-03-06 12:26   ` Lorenzo Stoakes (Oracle)
2026-03-11  8:18     ` David Hildenbrand (Arm)
2026-02-27 20:08 ` [PATCH v1 11/16] mm/memory: inline unmap_page_range() into __zap_vma_range() David Hildenbrand (Arm)
2026-03-06 12:29   ` Lorenzo Stoakes (Oracle)
2026-03-06 13:16     ` David Hildenbrand (Arm)
2026-03-09 13:46       ` Lorenzo Stoakes (Oracle)
2026-03-11  9:20         ` David Hildenbrand (Arm)
2026-02-27 20:08 ` [PATCH v1 12/16] mm: rename zap_vma_pages() to zap_vma() David Hildenbrand (Arm)
2026-03-06 12:30   ` Lorenzo Stoakes (Oracle)
2026-02-27 20:08 ` [PATCH v1 13/16] mm: rename zap_page_range_single_batched() to zap_vma_range_batched() David Hildenbrand (Arm)
2026-03-06 12:31   ` Lorenzo Stoakes (Oracle)
2026-02-27 20:08 ` [PATCH v1 14/16] mm: rename zap_page_range_single() to zap_vma_range() David Hildenbrand (Arm)
2026-02-28 12:44   ` Alice Ryhl
2026-03-02  8:22     ` David Hildenbrand (Arm)
2026-03-06 12:32   ` Lorenzo Stoakes (Oracle)
2026-03-09 16:46   ` Puranjay Mohan
2026-02-27 20:08 ` [PATCH v1 15/16] mm: rename zap_vma_ptes() to zap_special_vma_range() David Hildenbrand (Arm)
2026-03-04 15:26   ` Leon Romanovsky
2026-03-06 12:41   ` Lorenzo Stoakes (Oracle)
2026-03-11  8:20     ` David Hildenbrand (Arm)
2026-02-27 20:08 ` [PATCH v1 16/16] mm/memory: support VM_MIXEDMAP in zap_special_vma_range() David Hildenbrand (Arm)
2026-03-06 12:43   ` Lorenzo Stoakes (Oracle)
2026-03-09 14:29   ` Jason Gunthorpe
2026-03-11  9:15     ` David Hildenbrand (Arm)
2026-03-11  9:38       ` Alice Ryhl
2026-03-11 12:04         ` Jason Gunthorpe
2026-03-11 16:01           ` Alice Ryhl
2026-03-02 23:29 ` [PATCH v1 00/16] mm: cleanups around unmapping / zapping Andrew Morton

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=20260227200848.114019-9-david@kernel.org \
    --to=david@kernel.org \
    --cc=Liam.Howlett@oracle.com \
    --cc=abbotti@mev.co.uk \
    --cc=acme@kernel.org \
    --cc=agordeev@linux.ibm.com \
    --cc=airlied@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=aliceryhl@google.com \
    --cc=andrii@kernel.org \
    --cc=arnd@arndb.de \
    --cc=arve@android.com \
    --cc=ast@kernel.org \
    --cc=borntraeger@linux.ibm.com \
    --cc=bp@alien8.de \
    --cc=bpf@vger.kernel.org \
    --cc=brauner@kernel.org \
    --cc=cmllamas@google.com \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=dimitri.sivanich@hpe.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=frankja@linux.ibm.com \
    --cc=gerald.schaefer@linux.ibm.com \
    --cc=gor@linux.ibm.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hca@linux.ibm.com \
    --cc=hsweeten@visionengravers.com \
    --cc=imbrenda@linux.ibm.com \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jani.nikula@linux.intel.com \
    --cc=jannh@google.com \
    --cc=jarkko@kernel.org \
    --cc=jgg@ziepe.ca \
    --cc=joonas.lahtinen@linux.intel.com \
    --cc=kuba@kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=leon@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=linux-rdma@vger.kernel.org \
    --cc=linux-s390@vger.kernel.org \
    --cc=linux-sgx@vger.kernel.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=luto@kernel.org \
    --cc=maddy@linux.ibm.com \
    --cc=mhocko@suse.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=namhyung@kernel.org \
    --cc=ncardwell@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=ojeda@kernel.org \
    --cc=pabeni@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pfalcato@suse.de \
    --cc=rientjes@google.com \
    --cc=rodrigo.vivi@intel.com \
    --cc=rppt@kernel.org \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=shakeel.butt@linux.dev \
    --cc=simona@ffwll.ch \
    --cc=surenb@google.com \
    --cc=tglx@kernel.org \
    --cc=tkjos@android.com \
    --cc=tursulin@ursulin.net \
    --cc=vbabka@kernel.org \
    --cc=vincenzo.frascino@arm.com \
    --cc=willy@infradead.org \
    --cc=x86@kernel.org \
    /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.