From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9BDD05372E1 for ; Tue, 13 Oct 2026 18:52:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791917570; cv=none; b=kJDxNsTi2wVsQ13YvtfkmXobPfAzCJ+8/jDEC2uYYrCuL0db/DF8IoqSqy13VW7Y/PZASVILG9ISu5BE6Bztlk2YWlZqp5liFf4hXe0R15+htSawxQXEmpBa9IvmXQ8hR72+h23QXIK81yuQkDgZfrctlSlVYRTgrW3bR0y0c2I= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1791917570; c=relaxed/simple; bh=D9+5gDsg/eZTqx31wA8kbuA371R/5aELHSM/qG6hOac=; h=Date:To:From:Subject:Message-Id; b=J4LppICVPQJKuHj7fZCv+mzywLkdiHRLqgRmPvV8n8ynk8cegNMpm/T1BAC4IWAvxCxKgdCQZOlZn0IKpcdbcwwoJwW9chyp9ya1L3oRKVL8PK2HrwZLj/R6sMAYR4nK1Edtr5zhhA4EeQHxUBtfef9S9bNobhFucxYxecQ0yuc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b=gYZi9VwE; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux-foundation.org header.i=@linux-foundation.org header.b="gYZi9VwE" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6ED601F00893; Tue, 13 Oct 2026 18:52:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=korg; t=1791917568; bh=o8V9iuJeaiUHNduWsMtHzCiRqZD17iTEd6nHJJD6fko=; h=Date:To:From:Subject; b=gYZi9VwETEOye0erCWGXPqYIJnmPlP4mxflLaFLFECbyhnZ9EgiYoFHL46Yy0f+dg tvR+X4ARnxYzzM/dVVepUvzc+PWPhoIs73YyM+myKkPWCjAoWDcplG+dzBOMW2laIC 2vF49FExw+BgY7Shz3xzbXdtK35QczdQmsNS34TM= Date: Tue, 13 Oct 2026 11:52:48 -0700 To: mm-commits@vger.kernel.org,ljs@kernel.org,akpm@linux-foundation.org From: Andrew Morton Subject: + mm-madvise-update-is_valid_guard_vma-to-use-vma_is_mm_backed.patch added to mm-unstable branch Message-Id: <20261013185248.6ED601F00893@smtp.kernel.org> Precedence: bulk X-Mailing-List: mm-commits@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: The patch titled Subject: mm/madvise: update is_valid_guard_vma() to use vma_is_mm_backed() has been added to the -mm mm-unstable branch. Its filename is mm-madvise-update-is_valid_guard_vma-to-use-vma_is_mm_backed.patch This patch will shortly appear at https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patches/mm-madvise-update-is_valid_guard_vma-to-use-vma_is_mm_backed.patch This patch will later appear in the mm-unstable branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm Before you just go and hit "reply", please: a) Consider who else should be cc'ed b) Prefer to cc a suitable mailing list as well c) Ideally: find the original patch on the mailing list and do a reply-to-all to that, adding suitable additional cc's *** Remember to use Documentation/process/submit-checklist.rst when testing your code *** The -mm tree is included into linux-next via various branches at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm and is updated there most days ------------------------------------------------------ From: "Lorenzo Stoakes (ARM)" Subject: mm/madvise: update is_valid_guard_vma() to use vma_is_mm_backed() Date: Tue, 13 Oct 2026 16:05:11 +0100 We currently disallow the installation of lightweight guard regions in VMAs whose flags intersect VMA_SPECIAL_FLAGS or VMA_HUGETLB_BIT, or VMA_LOCKED_BIT unless allow_locked is set. hugetlb VMAs set VMA_DONTEXPAND_BIT so this was already redundant, VMA_SPECIAL_FLAGS already sufficed. However, now that VMA_IO_BIT is only set if VMA_PFNMAP or VMA_MIXEDMAP_BIT is set, this check collapses to being the equivalent of !vma_is_mm_backed(), excluding hugetlb mappings in which guard markers cannot be installed. Update is_valid_guard_vma() to reflect this. No functional change intended. Link: https://lore.kernel.org/20261013-b4-mmap-prepare-vma-flag-sanify-v6-31-1aa3c9b139f9@kernel.org Signed-off-by: Lorenzo Stoakes (ARM) Signed-off-by: Andrew Morton Acked-by: Zi Yan Acked-by: David Hildenbrand (Arm) Cc: Liam R. Howlett Cc: Vlastimil Babka Cc: Jann Horn Cc: Pedro Falcato Cc: Mike Rapoport Cc: Suren Baghdasaryan Cc: Michal Hocko Cc: Jonathan Corbet Cc: Greg Kroah-Hartman Cc: Dennis Dalessandro Cc: Jason Gunthorpe Cc: Leon Romanovsky Cc: Paul Moore Cc: Stephen Smalley Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Alexei Starovoitov Cc: Daniel Borkmann Cc: Andrii Nakryiko Cc: Eduard Zingerman Cc: Kumar Kartikeya Dwivedi Cc: Baolin Wang Cc: Nico Pache Cc: Ryan Roberts Cc: Dev Jain Cc: Barry Song Cc: Lance Yang Cc: Usama Arif Cc: Kiryl Shutsemau Cc: Doug Gilbert Cc: James Bottomley Cc: Martin K. Petersen Cc: Simona Vetter Cc: Helge Deller Cc: Sebastian Reichel Cc: John Hubbard Cc: Peter Xu Cc: Masami Hiramatsu Cc: Oleg Nesterov Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: Ingo Molnar Cc: Borislav Petkov Cc: Dave Hansen Cc: Arnaldo Carvalho de Melo Cc: Namhyung Kim Cc: Mark Rutland Cc: Rik van Riel Cc: Harry Yoo Cc: Juri Lelli Cc: Vincent Guittot Cc: Maarten Lankhorst Cc: Maxime Ripard Cc: Thomas Zimmermann Cc: David Airlie Cc: Will Deacon Cc: Aneesh Kumar K.V Cc: Nicholas Piggin Cc: Arnd Bergmann Cc: Muchun Song Cc: Oscar Salvador Cc: Matthew Wilcox (Oracle) Cc: Jan Kara Cc: Marc Zyngier Cc: Oliver Upton Cc: Catalin Marinas Cc: Madhavan Srinivasan Cc: Anup Patel Cc: Paul Walmsley Cc: Palmer Dabbelt Cc: Albert Ou Cc: Christian Borntraeger Cc: Janosch Frank Cc: Claudio Imbrenda Cc: Alexander Gordeev Cc: Gerald Schaefer Cc: Heiko Carstens Cc: Vasily Gorbik Cc: David S. Miller Cc: Andreas Larsson Cc: Al Viro Cc: Christian Brauner Cc: Matthew Brost Cc: Joshua Hahn Cc: Rakie Kim Cc: Byungchul Park Cc: Gregory Price Cc: Ying Huang Cc: Alistair Popple Cc: Chris Li Cc: Kairui Song Cc: Kemeng Shi Cc: Nhat Pham Cc: Baoquan He Cc: Youngjun Park Cc: Johannes Weiner Cc: Qi Zheng Cc: Shakeel Butt Cc: Axel Rasmussen Cc: Yuanchu Xie Cc: Wei Xu Cc: Chengming Zhou Cc: Michal Hocko Cc: Miklos Szeredi Cc: Xu Xin Cc: Ihor Solodrai Cc: Bert Karwatzki --- mm/madvise.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) --- a/mm/madvise.c~mm-madvise-update-is_valid_guard_vma-to-use-vma_is_mm_backed +++ a/mm/madvise.c @@ -1057,19 +1057,25 @@ static long madvise_remove(struct madvis return error; } -static bool is_valid_guard_vma(struct vm_area_struct *vma, bool allow_locked) +static bool is_valid_guard_vma(const struct vm_area_struct *vma, + bool allow_locked) { - vm_flags_t disallowed = VM_SPECIAL | VM_HUGETLB; - /* - * A user could lock after setting a guard range but that's fine, as + * A user could lock after setting a guard range but that's fine as * they'd not be able to fault in. The issue arises when we try to zap * existing locked VMAs. We don't want to do that. */ - if (!allow_locked) - disallowed |= VM_LOCKED; + if (!allow_locked && vma_test(vma, VMA_LOCKED_BIT)) + return false; + /* + * Guard regions require a VMA whose page tables are managed solely by + * core mm, so the VMA must be mm-backed (excluding hugetlb, in which + * guard markers cannot be installed). + */ + if (!vma_is_mm_backed(vma) || vma_is_hugetlb(vma)) + return false; - return !(vma->vm_flags & disallowed); + return true; } static bool is_guard_pte_marker(pte_t ptent) _ Patches currently in -mm which might be from ljs@kernel.org are mm-vma-fix-mmap_prepare-file-handling-remove-file_doesnt_need_get.patch mm-vma-introduce-and-use-vma_can_merge.patch mm-consistently-validate-vma-state-after-mmap-hooks.patch mm-vma-ensure-mmap_prepare-doesnt-set-actions-on-a-mergeable-vma.patch mm-make-map_kernel_pages_-internal-and-unexported.patch mm-vma-tidy-up-map-kernel-pages-enum-values.patch mm-assert-mmap-lock-held-use-new-flags-api-in-vm_insert_page.patch mm-add-mmap-action-for-discontiguous-kernel-page-mapping.patch docs-filesystems-update-mmap_prepare-docs-for-discontig-kernel-pgs.patch drivers-usb-mon-update-to-use-mmap_prepare-map-kernel-pages.patch infiniband-update-hfi1-to-use-remap_vmalloc_range.patch selinux-reject-writable-opens-of-policy-file-drop-mmap-shared-write-check.patch alsa-pcm-use-vm_insert_page-to-map-pcm-status-page.patch bpf-arena-mark-arena_map_mmap-mappings-vm_mixedmap.patch mm-vma-add-vma_is_mm_managed-predicates.patch mm-vma-only-allow-mmap-to-clear-vma_maywrite_bit-if-not-mm-managed.patch mm-vma-add-and-use-vma__is_fixed_mapping.patch scsi-sg-convert-mmap-hook-to-mmap_prepare-and-rework.patch fbdev-defio-assert-fbinfo_virtfb-drop-vm_io-add-vm_mixedmap.patch hsi-cmt_speech-convert-mmap-hook-to-mmap_prepare-refactor.patch mm-gup-error-out-early-on-vma_mayread_bit-vmas.patch uprobes-remove-vm_io-set-vm_mixedmap-for-mapped-kernel-pages.patch mm-mlock-clear-vma_locked_mask-over-mmap-callback.patch mm-mlock-eliminate-weird-vma_io_bit-abuse-and-simplify.patch mm-vma-enforce-that-mm-managed-mappings-may-not-set-vma_io_bit.patch mm-remove-vma_io_bit-check-in-vma_is_mm_managed.patch mm-remove-hugetlb_inlineh.patch mm-rename-is_vm_hugetlb_page-to-vma_is_hugetlb.patch mm-drop-some-redundant-checks-around-hugetlb-vmas.patch mm-vma-introduce-vma_is_mm_backed.patch mm-madvise-update-is_valid_guard_vma-to-use-vma_is_mm_backed.patch mm-uffd-use-predicates-for-userfaultfd-checks.patch mm-madvise-use-predicates-for-madvise-madv_dofork.patch mm-eliminate-vma_special_flags-usage-when-hugetlb-explicitly-tested.patch mm-eliminate-vma_special_flags-check-in-lru_gen_look_around.patch mm-avoid-use-of-vma_special_flags-in-migrate_vma_setup.patch mm-eliminate-vm_special-vma_special_flags.patch fuse-dax-do-not-set-vm_mixedmap.patch mm-huge_memory-remove-vma_is_special_huge.patch mm-vma-const-ify-vma_assert_stabilised-and-associated-functions.patch mm-implement-and-use-vma_has_anon_rmap-silence-kcsan.patch mm-update-comments-to-refer-to-anon-rmap-rather-than-anon_vma.patch mm-vma-dont-remove-vma-from-rmap-if-pgoff-unchanged.patch