From: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>,
"Liam R. Howlett" <liam@infradead.org>,
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>,
Davidlohr Bueso <dave@stgolabs.net>, SJ Park <sj@kernel.org>,
Kees Cook <kees@kernel.org>, Colin Cross <ccross@google.com>
Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org,
"Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
stable@vger.kernel.org
Subject: [PATCH 2/4] mm/vma: write lock source VMA before duplicating it in __split_vma()
Date: Fri, 23 Oct 2026 14:47:28 +0100 [thread overview]
Message-ID: <20261023-fix-vma-atomic-v1-2-8ff4fae1fc85@kernel.org> (raw)
In-Reply-To: <20261023-fix-vma-atomic-v1-0-8ff4fae1fc85@kernel.org>
From: "David Hildenbrand (Arm)" <david@kernel.org>
__split_vma() duplicates the source VMA before taking its VMA write lock,
and until the VMA is write-locked, a concurrent thread might set
VMA_MAYBE_GUARD_BIT, resulting in the duplication missing the flag.
If this happens, then fork may fail to duplicate guard markers and, if a
file-backed mapping, THP collapse may also discard the markers.
Resolve this by taking the VMA write lock before vm_area_dup() and, since
all callers of vm_area_dup() now hold the VMA write lock, assert that this
is the case there, and add a comment to explain why it's needed.
Fixes: 2ab7f1bbafc9 ("mm/madvise: allow guard page install/remove under VMA lock")
Cc: <stable@vger.kernel.org>
Signed-off-by: David Hildenbrand (Arm) <david@kernel.org>
Reviewed-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
[ ljs - add VMA write assert in vm_area_dup(), commit message touchup ]
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
mm/vma.c | 2 +-
mm/vma_init.c | 3 +++
2 files changed, 4 insertions(+), 1 deletion(-)
diff --git a/mm/vma.c b/mm/vma.c
index 1be613044b4a..aa59005e2f42 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -538,6 +538,7 @@ __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma,
return err;
}
+ vma_start_write(vma);
new = vm_area_dup(vma);
if (!new)
return -ENOMEM;
@@ -568,7 +569,6 @@ __split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma,
if (new->vm_ops && new->vm_ops->open)
new->vm_ops->open(new);
- vma_start_write(vma);
vma_start_write(new);
init_vma_prep(&vp, vma);
diff --git a/mm/vma_init.c b/mm/vma_init.c
index baa7e82f47e3..d661f229a734 100644
--- a/mm/vma_init.c
+++ b/mm/vma_init.c
@@ -127,6 +127,9 @@ struct vm_area_struct *vm_area_dup(struct vm_area_struct *orig)
{
struct vm_area_struct *new = kmem_cache_alloc(vm_area_cachep, GFP_KERNEL);
+ /* Must hold a write lock to stabilise atomic VMA flags. */
+ vma_assert_write_locked(orig);
+
if (!new)
return NULL;
--
2.56.0
next prev parent reply other threads:[~2026-10-23 13:48 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-23 13:47 [PATCH 0/4] mm: avoid losing atomic VMA flags Lorenzo Stoakes (ARM)
2026-10-23 13:47 ` [PATCH 1/4] mm: do not unintentionally overwrite " Lorenzo Stoakes (ARM)
2026-10-26 10:47 ` David Hildenbrand (Arm)
2026-10-26 12:49 ` Pedro Falcato
2026-10-23 13:47 ` Lorenzo Stoakes (ARM) [this message]
2026-10-23 19:26 ` [PATCH 2/4] mm/vma: write lock source VMA before duplicating it in __split_vma() Davidlohr Bueso
2026-10-26 10:42 ` David Hildenbrand (Arm)
2026-10-26 10:44 ` Lorenzo Stoakes (ARM)
2026-10-26 12:57 ` Pedro Falcato
2026-10-23 13:47 ` [PATCH 3/4] mm/madvise: preserve VMA_SOFTDIRTY_BIT when changing anonymous names Lorenzo Stoakes (ARM)
2026-10-26 13:04 ` Pedro Falcato
2026-10-23 13:47 ` [PATCH 4/4] mm/vma: avoid losing atomic VMA flags when setting sticky VMA flags Lorenzo Stoakes (ARM)
2026-10-26 10:50 ` David Hildenbrand (Arm)
2026-10-26 13:07 ` Pedro Falcato
2026-10-23 19:08 ` [PATCH 0/4] mm: avoid losing atomic " Andrew Morton
2026-10-27 1:51 ` Gregory Price (Meta)
2026-10-27 8:34 ` Lorenzo Stoakes (ARM)
2026-10-27 11:38 ` Gregory Price (Meta)
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=20261023-fix-vma-atomic-v1-2-8ff4fae1fc85@kernel.org \
--to=ljs@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=ccross@google.com \
--cc=dave@stgolabs.net \
--cc=david@kernel.org \
--cc=jannh@google.com \
--cc=kees@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=sj@kernel.org \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@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.