* FAILED: patch "[PATCH] mm/vma: reset VMA iterator on commit_merge() OOM failure" failed to apply to 6.12-stable tree
@ 2025-06-20 15:11 gregkh
2025-06-30 17:58 ` [PATCH 6.12.y] mm/vma: reset VMA iterator on commit_merge() OOM failure Lorenzo Stoakes
0 siblings, 1 reply; 3+ messages in thread
From: gregkh @ 2025-06-20 15:11 UTC (permalink / raw)
To: lorenzo.stoakes, Liam.Howlett, akpm, jannh, pfalcato, stable,
vbabka; +Cc: stable
The patch below does not apply to the 6.12-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable@vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/ linux-6.12.y
git checkout FETCH_HEAD
git cherry-pick -x 0cf4b1687a187ba9247c71721d8b064634eda1f7
# <resolve conflicts, build, test, etc.>
git commit -s
git send-email --to '<stable@vger.kernel.org>' --in-reply-to '2025062053-gills-deliverer-bafc@gregkh' --subject-prefix 'PATCH 6.12.y' HEAD^..
Possible dependencies:
thanks,
greg k-h
------------------ original commit in Linus's tree ------------------
From 0cf4b1687a187ba9247c71721d8b064634eda1f7 Mon Sep 17 00:00:00 2001
From: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Date: Fri, 6 Jun 2025 13:50:32 +0100
Subject: [PATCH] mm/vma: reset VMA iterator on commit_merge() OOM failure
While an OOM failure in commit_merge() isn't really feasible due to the
allocation which might fail (a maple tree pre-allocation) being 'too small
to fail', we do need to handle this case correctly regardless.
In vma_merge_existing_range(), we can theoretically encounter failures
which result in an OOM error in two ways - firstly dup_anon_vma() might
fail with an OOM error, and secondly commit_merge() failing, ultimately,
to pre-allocate a maple tree node.
The abort logic for dup_anon_vma() resets the VMA iterator to the initial
range, ensuring that any logic looping on this iterator will correctly
proceed to the next VMA.
However the commit_merge() abort logic does not do the same thing. This
resulted in a syzbot report occurring because mlockall() iterates through
VMAs, is tolerant of errors, but ended up with an incorrect previous VMA
being specified due to incorrect iterator state.
While making this change, it became apparent we are duplicating logic -
the logic introduced in commit 41e6ddcaa0f1 ("mm/vma: add give_up_on_oom
option on modify/merge, use in uffd release") duplicates the
vmg->give_up_on_oom check in both abort branches.
Additionally, we observe that we can perform the anon_dup check safely on
dup_anon_vma() failure, as this will not be modified should this call
fail.
Finally, we need to reset the iterator in both cases, so now we can simply
use the exact same code to abort for both.
We remove the VM_WARN_ON(err != -ENOMEM) as it would be silly for this to
be otherwise and it allows us to implement the abort check more neatly.
Link: https://lkml.kernel.org/r/20250606125032.164249-1-lorenzo.stoakes@oracle.com
Fixes: 47b16d0462a4 ("mm: abort vma_modify() on merge out of memory failure")
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reported-by: syzbot+d16409ea9ecc16ed261a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-mm/6842cc67.a00a0220.29ac89.003b.GAE@google.com/
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: Jann Horn <jannh@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
diff --git a/mm/vma.c b/mm/vma.c
index 726b2a31ce59..0fb9b2c7b734 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -967,26 +967,9 @@ static __must_check struct vm_area_struct *vma_merge_existing_range(
err = dup_anon_vma(next, middle, &anon_dup);
}
- if (err)
+ if (err || commit_merge(vmg))
goto abort;
- err = commit_merge(vmg);
- if (err) {
- VM_WARN_ON(err != -ENOMEM);
-
- if (anon_dup)
- unlink_anon_vmas(anon_dup);
-
- /*
- * We've cleaned up any cloned anon_vma's, no VMAs have been
- * modified, no harm no foul if the user requests that we not
- * report this and just give up, leaving the VMAs unmerged.
- */
- if (!vmg->give_up_on_oom)
- vmg->state = VMA_MERGE_ERROR_NOMEM;
- return NULL;
- }
-
khugepaged_enter_vma(vmg->target, vmg->flags);
vmg->state = VMA_MERGE_SUCCESS;
return vmg->target;
@@ -995,6 +978,9 @@ static __must_check struct vm_area_struct *vma_merge_existing_range(
vma_iter_set(vmg->vmi, start);
vma_iter_load(vmg->vmi);
+ if (anon_dup)
+ unlink_anon_vmas(anon_dup);
+
/*
* This means we have failed to clone anon_vma's correctly, but no
* actual changes to VMAs have occurred, so no harm no foul - if the
^ permalink raw reply related [flat|nested] 3+ messages in thread* [PATCH 6.12.y] mm/vma: reset VMA iterator on commit_merge() OOM failure
2025-06-20 15:11 FAILED: patch "[PATCH] mm/vma: reset VMA iterator on commit_merge() OOM failure" failed to apply to 6.12-stable tree gregkh
@ 2025-06-30 17:58 ` Lorenzo Stoakes
2025-07-01 1:15 ` Sasha Levin
0 siblings, 1 reply; 3+ messages in thread
From: Lorenzo Stoakes @ 2025-06-30 17:58 UTC (permalink / raw)
To: stable
While an OOM failure in commit_merge() isn't really feasible due to the
allocation which might fail (a maple tree pre-allocation) being 'too small
to fail', we do need to handle this case correctly regardless.
In vma_merge_existing_range(), we can theoretically encounter failures
which result in an OOM error in two ways - firstly dup_anon_vma() might
fail with an OOM error, and secondly commit_merge() failing, ultimately,
to pre-allocate a maple tree node.
The abort logic for dup_anon_vma() resets the VMA iterator to the initial
range, ensuring that any logic looping on this iterator will correctly
proceed to the next VMA.
However the commit_merge() abort logic does not do the same thing. This
resulted in a syzbot report occurring because mlockall() iterates through
VMAs, is tolerant of errors, but ended up with an incorrect previous VMA
being specified due to incorrect iterator state.
While making this change, it became apparent we are duplicating logic -
the logic introduced in commit 41e6ddcaa0f1 ("mm/vma: add give_up_on_oom
option on modify/merge, use in uffd release") duplicates the
vmg->give_up_on_oom check in both abort branches.
Additionally, we observe that we can perform the anon_dup check safely on
dup_anon_vma() failure, as this will not be modified should this call
fail.
Finally, we need to reset the iterator in both cases, so now we can simply
use the exact same code to abort for both.
We remove the VM_WARN_ON(err != -ENOMEM) as it would be silly for this to
be otherwise and it allows us to implement the abort check more neatly.
Link: https://lkml.kernel.org/r/20250606125032.164249-1-lorenzo.stoakes@oracle.com
Fixes: 47b16d0462a4 ("mm: abort vma_modify() on merge out of memory failure")
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Reported-by: syzbot+d16409ea9ecc16ed261a@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/linux-mm/6842cc67.a00a0220.29ac89.003b.GAE@google.com/
Reviewed-by: Pedro Falcato <pfalcato@suse.de>
Reviewed-by: Vlastimil Babka <vbabka@suse.cz>
Reviewed-by: Liam R. Howlett <Liam.Howlett@oracle.com>
Cc: Jann Horn <jannh@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
(cherry picked from commit 0cf4b1687a187ba9247c71721d8b064634eda1f7)
Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
---
mm/vma.c | 27 ++++++++-------------------
1 file changed, 8 insertions(+), 19 deletions(-)
diff --git a/mm/vma.c b/mm/vma.c
index 1d82ec4ee7bb..140f7017bb63 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -836,9 +836,6 @@ static struct vm_area_struct *vma_merge_existing_range(struct vma_merge_struct *
err = dup_anon_vma(next, vma, &anon_dup);
}
- if (err)
- goto abort;
-
/*
* In nearly all cases, we expand vmg->vma. There is one exception -
* merge_right where we partially span the VMA. In this case we shrink
@@ -846,22 +843,11 @@ static struct vm_area_struct *vma_merge_existing_range(struct vma_merge_struct *
*/
expanded = !merge_right || merge_will_delete_vma;
- if (commit_merge(vmg, adjust,
- merge_will_delete_vma ? vma : NULL,
- merge_will_delete_next ? next : NULL,
- adj_start, expanded)) {
- if (anon_dup)
- unlink_anon_vmas(anon_dup);
-
- /*
- * We've cleaned up any cloned anon_vma's, no VMAs have been
- * modified, no harm no foul if the user requests that we not
- * report this and just give up, leaving the VMAs unmerged.
- */
- if (!vmg->give_up_on_oom)
- vmg->state = VMA_MERGE_ERROR_NOMEM;
- return NULL;
- }
+ if (err || commit_merge(vmg, adjust,
+ merge_will_delete_vma ? vma : NULL,
+ merge_will_delete_next ? next : NULL,
+ adj_start, expanded))
+ goto abort;
res = merge_left ? prev : next;
khugepaged_enter_vma(res, vmg->flags);
@@ -873,6 +859,9 @@ static struct vm_area_struct *vma_merge_existing_range(struct vma_merge_struct *
vma_iter_set(vmg->vmi, start);
vma_iter_load(vmg->vmi);
+ if (anon_dup)
+ unlink_anon_vmas(anon_dup);
+
/*
* This means we have failed to clone anon_vma's correctly, but no
* actual changes to VMAs have occurred, so no harm no foul - if the
--
2.50.0
^ permalink raw reply related [flat|nested] 3+ messages in thread* Re: [PATCH 6.12.y] mm/vma: reset VMA iterator on commit_merge() OOM failure
2025-06-30 17:58 ` [PATCH 6.12.y] mm/vma: reset VMA iterator on commit_merge() OOM failure Lorenzo Stoakes
@ 2025-07-01 1:15 ` Sasha Levin
0 siblings, 0 replies; 3+ messages in thread
From: Sasha Levin @ 2025-07-01 1:15 UTC (permalink / raw)
To: stable, lorenzo.stoakes; +Cc: Sasha Levin
[ Sasha's backport helper bot ]
Hi,
Summary of potential issues:
⚠️ Found matching upstream commit but patch is missing proper reference to it
Found matching upstream commit: 0cf4b1687a187ba9247c71721d8b064634eda1f7
Status in newer kernel trees:
6.15.y | Present (different SHA1: b07a09cf2a1c)
Note: The patch differs from the upstream commit:
---
1: 0cf4b1687a187 ! 1: 2e6afa970267d mm/vma: reset VMA iterator on commit_merge() OOM failure
@@ Commit message
Cc: Jann Horn <jannh@google.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
+ (cherry picked from commit 0cf4b1687a187ba9247c71721d8b064634eda1f7)
+ Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
## mm/vma.c ##
-@@ mm/vma.c: static __must_check struct vm_area_struct *vma_merge_existing_range(
- err = dup_anon_vma(next, middle, &anon_dup);
+@@ mm/vma.c: static struct vm_area_struct *vma_merge_existing_range(struct vma_merge_struct *
+ err = dup_anon_vma(next, vma, &anon_dup);
}
- if (err)
-+ if (err || commit_merge(vmg))
- goto abort;
-
-- err = commit_merge(vmg);
-- if (err) {
-- VM_WARN_ON(err != -ENOMEM);
+- goto abort;
-
+ /*
+ * In nearly all cases, we expand vmg->vma. There is one exception -
+ * merge_right where we partially span the VMA. In this case we shrink
+@@ mm/vma.c: static struct vm_area_struct *vma_merge_existing_range(struct vma_merge_struct *
+ */
+ expanded = !merge_right || merge_will_delete_vma;
+
+- if (commit_merge(vmg, adjust,
+- merge_will_delete_vma ? vma : NULL,
+- merge_will_delete_next ? next : NULL,
+- adj_start, expanded)) {
- if (anon_dup)
- unlink_anon_vmas(anon_dup);
-
@@ mm/vma.c: static __must_check struct vm_area_struct *vma_merge_existing_range(
- vmg->state = VMA_MERGE_ERROR_NOMEM;
- return NULL;
- }
--
- khugepaged_enter_vma(vmg->target, vmg->flags);
- vmg->state = VMA_MERGE_SUCCESS;
- return vmg->target;
-@@ mm/vma.c: static __must_check struct vm_area_struct *vma_merge_existing_range(
++ if (err || commit_merge(vmg, adjust,
++ merge_will_delete_vma ? vma : NULL,
++ merge_will_delete_next ? next : NULL,
++ adj_start, expanded))
++ goto abort;
+
+ res = merge_left ? prev : next;
+ khugepaged_enter_vma(res, vmg->flags);
+@@ mm/vma.c: static struct vm_area_struct *vma_merge_existing_range(struct vma_merge_struct *
vma_iter_set(vmg->vmi, start);
vma_iter_load(vmg->vmi);
---
Results of testing on various branches:
| Branch | Patch Apply | Build Test |
|---------------------------|-------------|------------|
| stable/linux-6.12.y | Success | Success |
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2025-07-01 1:15 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-06-20 15:11 FAILED: patch "[PATCH] mm/vma: reset VMA iterator on commit_merge() OOM failure" failed to apply to 6.12-stable tree gregkh
2025-06-30 17:58 ` [PATCH 6.12.y] mm/vma: reset VMA iterator on commit_merge() OOM failure Lorenzo Stoakes
2025-07-01 1:15 ` Sasha Levin
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.