From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: sashiko-reviews@lists.linux.dev
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
"Jason Gunthorpe" <jgg@ziepe.ca>,
"John Hubbard" <jhubbard@nvidia.com>,
"Peter Xu" <peterx@redhat.com>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Jan Kara" <jack@suse.cz>, "Rik van Riel" <riel@surriel.com>,
"Liam R. Howlett" <liam@infradead.org>,
"Vlastimil Babka" <vbabka@kernel.org>,
"Harry Yoo" <harry@kernel.org>, "Jann Horn" <jannh@google.com>,
"Lance Yang" <lance.yang@linux.dev>, "Zi Yan" <ziy@nvidia.com>,
"Matthew Brost" <matthew.brost@intel.com>,
"Joshua Hahn" <joshua.hahnjy@gmail.com>,
"Byungchul Park" <byungchul@sk.com>,
"Gregory Price" <gourry@gourry.net>,
"Ying Huang" <ying.huang@linux.alibaba.com>,
"Alistair Popple" <apopple@nvidia.com>,
"Baolin Wang" <baolin.wang@linux.alibaba.com>,
"Nico Pache" <nico.pache@linux.dev>,
"Ryan Roberts" <ryan.roberts@arm.com>,
"Dev Jain" <dev.jain@arm.com>, "Barry Song" <baohua@kernel.org>,
"Usama Arif" <usama.arif@linux.dev>,
"Kiryl Shutsemau" <kas@kernel.org>, "Xu Xin" <xu.xin@linux.dev>,
"Chengming Zhou" <chengming.zhou@linux.dev>,
"Madhavan Srinivasan" <maddy@linux.ibm.com>,
"Nicholas Piggin" <npiggin@gmail.com>,
"Michael Ellerman" <mpe@ellerman.id.au>,
"Christophe Leroy (CS GROUP)" <chleroy@kernel.org>,
"Ritesh Harjani (IBM)" <ritesh.list@gmail.com>,
"Shrikanth Hegde" <sshegde@linux.ibm.com>,
"Pedro Falcato" <pfalcato@suse.de>,
"Kairui Song" <kasong@tencent.com>,
"Qi Zheng" <qi.zheng@linux.dev>,
"Shakeel Butt" <shakeel.butt@linux.dev>,
"Axel Rasmussen" <axelrasmussen@google.com>,
"Yuanchu Xie" <yuanchu@google.com>, "Wei Xu" <weixugc@google.com>,
"Baoquan He" <baoquan.he@linux.dev>,
"Mike Rapoport" <rppt@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
"Michal Hocko" <mhocko@suse.com>,
"Leon Romanovsky" <leon@kernel.org>, "SJ Park" <sj@kernel.org>,
"Rakie Kim" <rakie.kim@sk.com>,
"David Rientjes" <rientjes@google.com>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
"Christian Brauner" <brauner@kernel.org>,
"Peter Zijlstra" <peterz@infradead.org>,
"Ingo Molnar" <mingo@redhat.com>,
"Arnaldo Carvalho de Melo" <acme@kernel.org>,
"Namhyung Kim" <namhyung@kernel.org>,
"Mark Rutland" <mark.rutland@arm.com>,
"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
"Jiri Olsa" <jolsa@kernel.org>, "Ian Rogers" <irogers@google.com>,
"Adrian Hunter" <adrian.hunter@intel.com>,
"James Clark" <james.clark@linaro.org>,
"Masami Hiramatsu" <mhiramat@kernel.org>,
"Oleg Nesterov" <oleg@redhat.com>,
"John Johansen" <john.johansen@canonical.com>,
"Georgia Garcia" <georgia.garcia@canonical.com>,
"Paul Moore" <paul@paul-moore.com>,
"James Morris" <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Roberto Sassu" <roberto.sassu@huawei.com>,
"Dmitry Kasatkin" <dmitry.kasatkin@gmail.com>,
"Eric Snowberg" <eric.snowberg@oracle.com>,
"Fan Wu" <wufan@kernel.org>,
"Stephen Smalley" <stephen.smalley.work@gmail.com>,
"Ondrej Mosnáček" <omosnacek@gmail.com>,
linux-mm@kvack.org, kvm@vger.kernel.org, damon@lists.linux.dev,
linux-trace-kernel@vger.kernel.org,
linux-perf-users@vger.kernel.org, apparmor@lists.ubuntu.com,
linux-security-module@vger.kernel.org, selinux@vger.kernel.org
Subject: Re: [PATCH 02/13] mm/filemap: convert fault and readahead logic to use vma_flags_t
Date: Fri, 6 Nov 2026 11:53:00 +0000 [thread overview]
Message-ID: <au2_PPpdAMgRJZtX@gremlin> (raw)
In-Reply-To: <sashiko-outbox-200257@kernel.org>
On Thu, Nov 05, 2026 at 09:41:34PM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
> - [High] mm/filemap: use-after-free on vma in do_sync_mmap_readahead()
> - [Low] mm/filemap: inner vma declaration shadows outer vma in do_sync_mmap_readahead()
> --
>
> commit f5f0f8e634a6a2e2b76ad818de67e83f30cb7dea
> Author: Lorenzo Stoakes (ARM) <ljs@kernel.org>
>
> mm/filemap: convert fault and readahead logic to use vma_flags_t
>
> This commit replaces direct checks of vm_flags_t values with vma_flags_t
> helpers in the filemap fault and mmap readahead paths.
>
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index b74bc1e5015c6..d8b538bd14043 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -3351,13 +3351,14 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
> > struct address_space *mapping = file->f_mapping;
> > DEFINE_READAHEAD(ractl, file, ra, mapping, vmf->pgoff);
> > struct file *fpin = NULL;
> > - vm_flags_t vm_flags = vmf->vma->vm_flags;
> > + struct vm_area_struct *vma = vmf->vma;
> > bool force_thp_readahead = false;
> > unsigned int thp_order = 0;
> > unsigned short mmap_miss;
>
> [ ... ]
>
> > @@ -3414,7 +3416,7 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
> > * Fetch two folios so we get the chance to actually
> > * readahead, unless we've been told not to.
> > */
> > - if (!(vm_flags & VM_RAND_READ))
> > + if (!vma_test(vma, VMA_RAND_READ_BIT))
> > ra->size *= 2;
> > ra->async_size = folio_nr_pages;
> > ra->order = thp_order;
>
> [Severity: High]
> Can this trigger a use-after-free on vma?
>
> Previously, do_sync_mmap_readahead() cached vmf->vma->vm_flags by value in a
> local variable at entry while the fault lock was held, as introduced by
> commit dcfa24ba6899 ("filemap: Cache the value of vm_flags").
>
> In the force_thp_readahead block, maybe_unlock_mmap_for_io() is called before
> this check:
>
> if (force_thp_readahead) {
> unsigned long folio_nr_pages = 1UL << thp_order;
>
> fpin = maybe_unlock_mmap_for_io(vmf, fpin);
> ractl._index &= ~(folio_nr_pages - 1);
> ra->size = folio_nr_pages;
> /*
> * Fetch two folios so we get the chance to actually
> * readahead, unless we've been told not to.
> */
> if (!vma_test(vma, VMA_RAND_READ_BIT))
> ra->size *= 2;
>
> Since maybe_unlock_mmap_for_io() only pins vmf->vma->vm_file and calls
> release_fault_lock(vmf) to drop mmap_lock or the per-VMA lock, isn't vma
> unprotected against concurrent modification or freeing when vma_test(vma,
> VMA_RAND_READ_BIT) dereferences vma->flags?
>
> > @@ -3422,7 +3424,7 @@ static struct file *do_sync_mmap_readahead(struct vm_fault *vmf)
> > return fpin;
> > }
> >
> > - if (vm_flags & VM_EXEC) {
> > + if (vma_test(vma, VMA_EXEC_BIT)) {
> > /*
> > * Allow arch to request a preferred minimum folio order for
> > * executable memory. This can often be beneficial to
>
> [Severity: Low]
> Does the newly added outer vma declaration in do_sync_mmap_readahead() cause
> the existing inner declaration in this VMA_EXEC_BIT block to shadow it?
>
> if (vma_test(vma, VMA_EXEC_BIT)) {
> ...
> struct vm_area_struct *vma = vmf->vma;
> const unsigned long start = vma_start_pgoff(vma);
> const unsigned long end = vma_end_pgoff(vma);
>
> Should the inner vma variable be removed now that vma is declared at function
> scope?
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20261105-late-2026-vma-flags-v1-0-0d3cd15ab75f@kernel.org?part=2
It seems these are valid, oops!
Andrew suggested a fix off-list, and I agreed to this as an in-place fixup to
avoid respin.
I have also updated the series locally to reflect this change:
----8<----
mm/filemap.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
--- a/mm/filemap.c~mm-filemap-convert-fault-and-readahead-logic-to-use-vma_flags_t-fix
+++ a/mm/filemap.c
@@ -3410,6 +3410,7 @@ static struct file *do_sync_mmap_readahe
if (force_thp_readahead) {
unsigned long folio_nr_pages = 1UL << thp_order;
+ const bool random_read = vma_test(vma, VMA_RAND_READ_BIT);
fpin = maybe_unlock_mmap_for_io(vmf, fpin);
ractl._index &= ~(folio_nr_pages - 1);
@@ -3418,7 +3419,7 @@ static struct file *do_sync_mmap_readahe
* Fetch two folios so we get the chance to actually
* readahead, unless we've been told not to.
*/
- if (!vma_test(vma, VMA_RAND_READ_BIT))
+ if (!random_read)
ra->size *= 2;
ra->async_size = folio_nr_pages;
ra->order = thp_order;
@@ -3438,7 +3439,6 @@ static struct file *do_sync_mmap_readahe
* pad that might exist between sections, which would be a waste
* of memory.
*/
- struct vm_area_struct *vma = vmf->vma;
const unsigned long start = vma_start_pgoff(vma);
const unsigned long end = vma_end_pgoff(vma);
unsigned long ra_end;
_
--
Cheers, Lorenzo
next prev parent reply other threads:[~2026-11-06 11:53 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-05 21:30 [PATCH 00/13] mm: continue vma_flags_t conversion Lorenzo Stoakes (ARM)
2026-11-05 21:30 ` [PATCH 01/13] mm/gup: convert GUP code to use vma_flags_t Lorenzo Stoakes (ARM)
2026-11-05 21:38 ` sashiko-bot
2026-11-06 3:47 ` Barry Song
2026-11-06 5:47 ` Lance Yang
2026-11-09 13:32 ` David Hildenbrand
2026-11-05 21:30 ` [PATCH 02/13] mm/filemap: convert fault and readahead logic " Lorenzo Stoakes (ARM)
2026-11-05 21:41 ` sashiko-bot
2026-11-06 11:53 ` Lorenzo Stoakes (ARM) [this message]
2026-11-08 7:20 ` Barry Song
2026-11-08 7:42 ` Barry Song
2026-11-09 12:26 ` Lorenzo Stoakes (ARM)
2026-11-05 21:30 ` [PATCH 03/13] mm/rmap: convert remaining VMA flag tests " Lorenzo Stoakes (ARM)
2026-11-05 21:37 ` sashiko-bot
2026-11-06 3:04 ` Baolin Wang
2026-11-06 3:57 ` Barry Song
2026-11-06 11:21 ` Lorenzo Stoakes (ARM)
2026-11-06 5:54 ` Lance Yang
2026-11-09 13:31 ` David Hildenbrand
2026-11-05 21:30 ` [PATCH 04/13] mm/migrate: convert " Lorenzo Stoakes (ARM)
2026-11-05 21:39 ` sashiko-bot
2026-11-06 3:05 ` Baolin Wang
2026-11-06 4:10 ` Barry Song
2026-11-06 5:58 ` Lance Yang
2026-11-09 13:31 ` David Hildenbrand
2026-11-05 21:30 ` [PATCH 05/13] mm: convert THP " Lorenzo Stoakes (ARM)
2026-11-05 21:40 ` sashiko-bot
2026-11-06 3:07 ` Baolin Wang
2026-11-06 4:01 ` Barry Song
2026-11-06 6:03 ` Lance Yang
2026-11-06 14:36 ` David Hildenbrand (Arm)
2026-11-09 12:27 ` Lorenzo Stoakes (ARM)
2026-11-09 13:38 ` David Hildenbrand
2026-11-05 21:30 ` [PATCH 06/13] mm/ksm: convert " Lorenzo Stoakes (ARM)
2026-11-05 21:40 ` sashiko-bot
2026-11-06 6:09 ` Lance Yang
2026-11-06 7:42 ` Xu Xin (vivo)
2026-11-09 13:30 ` David Hildenbrand
2026-11-05 21:30 ` [PATCH 07/13] mm/madvise: convert madvise_vma_behavior() " Lorenzo Stoakes (ARM)
2026-11-05 21:43 ` sashiko-bot
2026-11-06 6:38 ` Lance Yang
2026-11-09 13:44 ` David Hildenbrand (Arm)
2026-11-09 14:10 ` David Hildenbrand (Arm)
2026-11-09 17:01 ` Lorenzo Stoakes (ARM)
2026-11-05 21:30 ` [PATCH 08/13] mm: convert miscellaneous VMA flag tests " Lorenzo Stoakes (ARM)
2026-11-05 21:43 ` sashiko-bot
2026-11-06 1:01 ` SJ Park
2026-11-06 6:40 ` Lance Yang
2026-11-09 13:45 ` David Hildenbrand (Arm)
2026-11-12 5:36 ` Gregory Price (Meta)
2026-11-05 21:31 ` [PATCH 09/13] fs/proc/task_mmu: convert " Lorenzo Stoakes (ARM)
2026-11-05 21:45 ` sashiko-bot
2026-11-06 6:59 ` Lance Yang
2026-11-06 10:46 ` Lorenzo Stoakes (ARM)
2026-11-05 21:31 ` [PATCH 10/13] fs/coredump: convert vma_dump_size() " Lorenzo Stoakes (ARM)
2026-11-05 21:44 ` sashiko-bot
2026-11-06 7:03 ` Lance Yang
2026-11-05 21:31 ` [PATCH 11/13] uprobes: convert VMA flag tests " Lorenzo Stoakes (ARM)
2026-11-05 21:44 ` sashiko-bot
2026-11-06 7:12 ` Lance Yang
2026-11-05 21:31 ` [PATCH 12/13] perf: " Lorenzo Stoakes (ARM)
2026-11-05 21:46 ` sashiko-bot
2026-11-06 7:45 ` Lance Yang
2026-11-05 21:31 ` [PATCH 13/13] security: " Lorenzo Stoakes (ARM)
2026-11-05 21:46 ` sashiko-bot
2026-11-05 23:17 ` Paul Moore
2026-11-06 1:22 ` Paul Moore
2026-11-06 2:13 ` Fan Wu
2026-11-06 10:13 ` Lorenzo Stoakes (ARM)
2026-11-06 7:51 ` Lance Yang
2026-11-06 14:35 ` [PATCH 00/13] mm: continue vma_flags_t conversion David Hildenbrand (Arm)
2026-11-06 15:22 ` Lorenzo Stoakes (ARM)
2026-11-07 19:26 ` David Hildenbrand (Arm)
2026-11-07 20:09 ` Lorenzo Stoakes (ARM)
2026-11-09 13:40 ` David Hildenbrand (Arm)
2026-11-09 17:44 ` Andrew Morton
2026-11-09 17:48 ` David Hildenbrand (Arm)
2026-11-09 17:50 ` 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=au2_PPpdAMgRJZtX@gremlin \
--to=ljs@kernel.org \
--cc=acme@kernel.org \
--cc=adrian.hunter@intel.com \
--cc=akpm@linux-foundation.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=apopple@nvidia.com \
--cc=apparmor@lists.ubuntu.com \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=brauner@kernel.org \
--cc=byungchul@sk.com \
--cc=chengming.zhou@linux.dev \
--cc=chleroy@kernel.org \
--cc=damon@lists.linux.dev \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=eric.snowberg@oracle.com \
--cc=georgia.garcia@canonical.com \
--cc=gourry@gourry.net \
--cc=harry@kernel.org \
--cc=irogers@google.com \
--cc=jack@suse.cz \
--cc=james.clark@linaro.org \
--cc=jannh@google.com \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=jolsa@kernel.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=kasong@tencent.com \
--cc=kvm@vger.kernel.org \
--cc=lance.yang@linux.dev \
--cc=leon@kernel.org \
--cc=liam@infradead.org \
--cc=linux-mm@kvack.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=maddy@linux.ibm.com \
--cc=mark.rutland@arm.com \
--cc=matthew.brost@intel.com \
--cc=mhiramat@kernel.org \
--cc=mhocko@suse.com \
--cc=mingo@redhat.com \
--cc=mpe@ellerman.id.au \
--cc=namhyung@kernel.org \
--cc=nico.pache@linux.dev \
--cc=npiggin@gmail.com \
--cc=oleg@redhat.com \
--cc=omosnacek@gmail.com \
--cc=paul@paul-moore.com \
--cc=peterx@redhat.com \
--cc=peterz@infradead.org \
--cc=pfalcato@suse.de \
--cc=qi.zheng@linux.dev \
--cc=rakie.kim@sk.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=ritesh.list@gmail.com \
--cc=roberto.sassu@huawei.com \
--cc=rppt@kernel.org \
--cc=ryan.roberts@arm.com \
--cc=sashiko-reviews@lists.linux.dev \
--cc=selinux@vger.kernel.org \
--cc=serge@hallyn.com \
--cc=shakeel.butt@linux.dev \
--cc=sj@kernel.org \
--cc=sshegde@linux.ibm.com \
--cc=stephen.smalley.work@gmail.com \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=wufan@kernel.org \
--cc=xu.xin@linux.dev \
--cc=ying.huang@linux.alibaba.com \
--cc=yuanchu@google.com \
--cc=ziy@nvidia.com \
--cc=zohar@linux.ibm.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.