From: Andrew Morton <akpm@linux-foundation.org>
To: mm-commits@vger.kernel.org, ljs@kernel.org, akpm@linux-foundation.org
Cc: David Hildenbrand <david@kernel.org>
Subject: [to-be-updated] mm-gup-convert-gup-code-to-use-vma_flags_t.patch removed from -mm tree
Date: Mon, 09 Nov 2026 09:45:48 -0800 [thread overview]
Message-ID: <20261109174548.AA55D1F0089F@smtp.kernel.org> (raw)
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10504 bytes --]
The quilt patch titled
Subject: mm/gup: convert GUP code to use vma_flags_t
has been removed from the -mm tree. Its filename was
mm-gup-convert-gup-code-to-use-vma_flags_t.patch
This patch was dropped because an updated version will be issued
------------------------------------------------------
From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
Subject: mm/gup: convert GUP code to use vma_flags_t
Date: Thu, 05 Nov 2026 21:30:52 +0000
Patch series "mm: continue vma_flags_t conversion".
Continue the conversion of legacy vm_flags_t flags to the new vma_flags_t
bitmap type.
Do some more core mm conversion (we really should be the first to
completely move to the new scheme :), but also update some mm-adjacent and
otherwise straightforward cases - /proc/$pid/maps and friends, the coredump
VMA dump size logic, uprobes, perf and LSM mmap/mprotect hooks.
This series only makes strictly mechanical changes to keep things gentle
during this very busy cycle.
No functional change intended.
Build tested on x86-64 (allmodconfig, each patch individually), i386,
arm64, riscv nommu and ppc64le.
This patch (of 13):
Replace use of the legacy vm_flags_t flags with vma_flags_t values
throughout the GUP logic, both for the MMU and nommu variants.
No functional change intended.
Link: https://lore.kernel.org/20261105-late-2026-vma-flags-v1-0-0d3cd15ab75f@kernel.org
Link: https://lore.kernel.org/20261105-late-2026-vma-flags-v1-1-0d3cd15ab75f@kernel.org
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Barry Song <baohua@kernel.org>
Reviewed-by: Lance Yang <lance.yang@linux.dev>
Cc: David Hildenbrand <david@kernel.org>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: John Hubbard <jhubbard@nvidia.com>
Cc: Peter Xu <peterx@redhat.com>
Cc: Matthew Wilcox (Oracle) <willy@infradead.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Rik van Riel <riel@surriel.com>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Harry Yoo <harry@kernel.org>
Cc: Jann Horn <jannh@google.com>
Cc: Zi Yan <ziy@nvidia.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Cc: Joshua Hahn <joshua.hahnjy@gmail.com>
Cc: Byungchul Park <byungchul@sk.com>
Cc: Gregory Price <gourry@gourry.net>
Cc: Ying Huang <ying.huang@linux.alibaba.com>
Cc: Alistair Popple <apopple@nvidia.com>
Cc: Baolin Wang <baolin.wang@linux.alibaba.com>
Cc: Nico Pache <nico.pache@linux.dev>
Cc: Ryan Roberts <ryan.roberts@arm.com>
Cc: Dev Jain <dev.jain@arm.com>
Cc: Usama Arif <usama.arif@linux.dev>
Cc: Kiryl Shutsemau <kas@kernel.org>
Cc: Xu Xin <xu.xin@linux.dev>
Cc: Chengming Zhou <chengming.zhou@linux.dev>
Cc: Madhavan Srinivasan <maddy@linux.ibm.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Christophe Leroy <chleroy@kernel.org>
Cc: Ritesh Harjani (IBM) <ritesh.list@gmail.com>
Cc: Shrikanth Hegde <sshegde@linux.ibm.com>
Cc: Pedro Falcato <pfalcato@suse.de>
Cc: Kairui Song <kasong@tencent.com>
Cc: Qi Zheng <qi.zheng@linux.dev>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Axel Rasmussen <axelrasmussen@google.com>
Cc: Yuanchu Xie <yuanchu@google.com>
Cc: Wei Xu <weixugc@google.com>
Cc: Baoquan He <baoquan.he@linux.dev>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: SJ Park <sj@kernel.org>
Cc: Rakie Kim <rakie.kim@sk.com>
Cc: David Rientjes <rientjes@google.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Ian Rogers <irogers@google.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: James Clark <james.clark@linaro.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: John Johansen <john.johansen@canonical.com>
Cc: Georgia Garcia <georgia.garcia@canonical.com>
Cc: Paul Moore <paul@paul-moore.com>
Cc: James Morris <jmorris@namei.org>
Cc: Serge E. Hallyn <serge@hallyn.com>
Cc: Mimi Zohar <zohar@linux.ibm.com>
Cc: Roberto Sassu <roberto.sassu@huawei.com>
Cc: Dmitry Kasatkin <dmitry.kasatkin@gmail.com>
Cc: Eric Snowberg <eric.snowberg@oracle.com>
Cc: Fan Wu <wufan@kernel.org>
Cc: Stephen Smalley <stephen.smalley.work@gmail.com>
Cc: Ondrej Mosnáček <omosnacek@gmail.com>
---
mm/gup.c | 45 ++++++++++++++++++++++++---------------------
1 file changed, 24 insertions(+), 21 deletions(-)
--- a/mm/gup.c~mm-gup-convert-gup-code-to-use-vma_flags_t
+++ a/mm/gup.c
@@ -590,15 +590,15 @@ static inline bool can_follow_write_comm
return false;
/* But FOLL_FORCE has no effect on shared mappings */
- if (vma->vm_flags & (VM_MAYSHARE | VM_SHARED))
+ if (vma_test_any(vma, VMA_MAYSHARE_BIT, VMA_SHARED_BIT))
return false;
/* ... or read-only private ones */
- if (!(vma->vm_flags & VM_MAYWRITE))
+ if (!vma_test(vma, VMA_MAYWRITE_BIT))
return false;
/* ... or already writable ones that just need to take a write fault */
- if (vma->vm_flags & VM_WRITE)
+ if (vma_test(vma, VMA_WRITE_BIT))
return false;
/*
@@ -1203,12 +1203,11 @@ static bool writable_file_mapping_allowe
static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
{
- vm_flags_t vm_flags = vma->vm_flags;
int write = (gup_flags & FOLL_WRITE);
int foreign = (gup_flags & FOLL_REMOTE);
bool vma_anon = vma_is_anonymous(vma);
- if (vm_flags & (VM_IO | VM_PFNMAP))
+ if (vma_test_any(vma, VMA_IO_BIT, VMA_PFNMAP_BIT))
return -EFAULT;
if ((gup_flags & FOLL_ANON) && !vma_anon)
@@ -1228,7 +1227,8 @@ static int check_vma_flags(struct vm_are
!writable_file_mapping_allowed(vma, gup_flags))
return -EFAULT;
- if (!(vm_flags & VM_WRITE) || (vm_flags & VM_SHADOW_STACK)) {
+ if (!vma_test(vma, VMA_WRITE_BIT) ||
+ vma_test_single_mask(vma, VMA_SHADOW_STACK)) {
if (!(gup_flags & FOLL_FORCE))
return -EFAULT;
/*
@@ -1243,14 +1243,14 @@ static int check_vma_flags(struct vm_are
if (!vma_is_cow_mapping(vma))
return -EFAULT;
}
- } else if (!(vm_flags & VM_READ)) {
+ } else if (!vma_test(vma, VMA_READ_BIT)) {
if (!(gup_flags & FOLL_FORCE))
return -EFAULT;
/*
* Is there actually any vma we can reach here which does not
* have VM_MAYREAD set?
*/
- if (!(vm_flags & VM_MAYREAD))
+ if (!vma_test(vma, VMA_MAYREAD_BIT))
return -EFAULT;
}
/*
@@ -1281,7 +1281,7 @@ static struct vm_area_struct *gup_vma_lo
return vma;
/* Only warn for half-way relevant accesses */
- if (!(vma->vm_flags & VM_GROWSDOWN))
+ if (!vma_test(vma, VMA_GROWSDOWN_BIT))
return NULL;
if (vma->vm_start - addr > 65536)
return NULL;
@@ -1518,9 +1518,8 @@ static bool vma_permits_fault(struct vm_
{
bool write = !!(fault_flags & FAULT_FLAG_WRITE);
bool foreign = !!(fault_flags & FAULT_FLAG_REMOTE);
- vm_flags_t vm_flags = write ? VM_WRITE : VM_READ;
- if (!(vm_flags & vma->vm_flags))
+ if (!vma_test(vma, write ? VMA_WRITE_BIT : VMA_READ_BIT))
return false;
/*
@@ -1833,7 +1832,7 @@ long populate_vma_page_range(struct vm_a
* Rightly or wrongly, the VM_LOCKONFAULT case has never used
* faultin_page() to break COW, so it has no work to do here.
*/
- if (vma->vm_flags & VM_LOCKONFAULT)
+ if (vma_test(vma, VMA_LOCKONFAULT_BIT))
return nr_pages;
/* ... similarly, we've never faulted in PROT_NONE pages */
@@ -1853,7 +1852,7 @@ long populate_vma_page_range(struct vm_a
* Otherwise, do a read fault, and use FOLL_FORCE in case it's not
* readable (ie write-only or executable).
*/
- if ((vma->vm_flags & (VM_WRITE | VM_SHARED)) == VM_WRITE)
+ if (vma_test(vma, VMA_WRITE_BIT) && !vma_test(vma, VMA_SHARED_BIT))
gup_flags |= FOLL_WRITE;
else
gup_flags |= FOLL_FORCE;
@@ -1959,7 +1958,7 @@ int __mm_populate(unsigned long start, u
* range with the first VMA. Also, skip undesirable VMA types.
*/
nend = min(end, vma->vm_end);
- if (vma->vm_flags & (VM_IO | VM_PFNMAP))
+ if (vma_test_any(vma, VMA_IO_BIT, VMA_PFNMAP_BIT))
continue;
if (nstart < vma->vm_start)
nstart = vma->vm_start;
@@ -1990,7 +1989,7 @@ static long __get_user_pages_locked(stru
{
struct vm_area_struct *vma;
bool must_unlock = false;
- vm_flags_t vm_flags;
+ vma_flags_t vma_flags;
int ret, err = -EFAULT;
long i;
@@ -2015,10 +2014,14 @@ static long __get_user_pages_locked(stru
/* calculate required read or write permissions.
* If FOLL_FORCE is set, we only require the "MAY" flags.
*/
- vm_flags = (foll_flags & FOLL_WRITE) ?
- (VM_WRITE | VM_MAYWRITE) : (VM_READ | VM_MAYREAD);
- vm_flags &= (foll_flags & FOLL_FORCE) ?
- (VM_MAYREAD | VM_MAYWRITE) : (VM_READ | VM_WRITE);
+ if (foll_flags & FOLL_WRITE)
+ vma_flags = mk_vma_flags(VMA_WRITE_BIT, VMA_MAYWRITE_BIT);
+ else
+ vma_flags = mk_vma_flags(VMA_READ_BIT, VMA_MAYREAD_BIT);
+ if (foll_flags & FOLL_FORCE)
+ vma_flags_clear(&vma_flags, VMA_READ_BIT, VMA_WRITE_BIT);
+ else
+ vma_flags_clear(&vma_flags, VMA_MAYREAD_BIT, VMA_MAYWRITE_BIT);
for (i = 0; i < nr_pages; i++) {
vma = find_vma(mm, start);
@@ -2026,8 +2029,8 @@ static long __get_user_pages_locked(stru
break;
/* protect what we can, including chardevs */
- if ((vma->vm_flags & (VM_IO | VM_PFNMAP)) ||
- !(vm_flags & vma->vm_flags))
+ if (vma_test_any(vma, VMA_IO_BIT, VMA_PFNMAP_BIT) ||
+ !vma_test_any_mask(vma, vma_flags))
break;
if (pages) {
_
Patches currently in -mm which might be from ljs@kernel.org are
mm-vma-read-anon_vma-carefully-in-validate_mm.patch
mm-filemap-convert-fault-and-readahead-logic-to-use-vma_flags_t.patch
mm-rmap-convert-remaining-vma-flag-tests-to-use-vma_flags_t.patch
mm-migrate-convert-vma-flag-tests-to-use-vma_flags_t.patch
mm-convert-thp-vma-flag-tests-to-use-vma_flags_t.patch
mm-ksm-convert-vma-flag-tests-to-use-vma_flags_t.patch
mm-madvise-convert-madvise_vma_behavior-to-use-vma_flags_t.patch
mm-convert-miscellaneous-vma-flag-tests-to-use-vma_flags_t.patch
fs-proc-task_mmu-convert-vma-flag-tests-to-use-vma_flags_t.patch
fs-coredump-convert-vma_dump_size-to-use-vma_flags_t.patch
uprobes-convert-vma-flag-tests-to-use-vma_flags_t.patch
perf-convert-vma-flag-tests-to-use-vma_flags_t.patch
security-convert-vma-flag-tests-to-use-vma_flags_t.patch
reply other threads:[~2026-11-09 17:45 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20261109174548.AA55D1F0089F@smtp.kernel.org \
--to=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=ljs@kernel.org \
--cc=mm-commits@vger.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.