[PATCH] mm/vma: restore VMA iterator on full-range merge failure

[PATCH] mm/vma: restore VMA iterator on full-range merge failure

[shao.mingyin]

From: Shao Mingyin <shao.mingyin@zte.com.cn>

mm/vma: restore VMA iterator on full-range merge failure

vma_merge_existing_range() moves the iterator to the previous VMA when
merging to the left. If the range spans the whole middle VMA and a
vm_ops->close() hook prevents removing it, the function returns without
restoring the iterator.

An mprotect() walk can then visit the middle VMA again. Restore the
iterator to the range start, as the abort path already does. Extend the
existing close-hook merge test to check the iterator after this failure.
No crash or data corruption has been observed in this case.

Fixes: 01c373e9a5ce2 ("mm: rework vm_ops->close() handling on VMA merge")
Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>
---
Tested with tools/testing/vma using its default ASan/UBSan options.
The added iterator assertion fails before the fix; all 29 tests pass
with the fix. Also build-tested mm/vma.o with W=1 on x86_64.
This verifies iterator position, not a crash or a production workload.


 mm/vma.c                        | 5 ++++-
 tools/testing/vma/tests/merge.c | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/mm/vma.c b/mm/vma.c
index c82e9306b11ac14f684f44b8d71a0026b7fc145c..c87b29f1beec4ceb02c23f6b37af0e5dff272436 100644
--- a/mm/vma.c
+++ b/mm/vma.c
@@ -983,8 +983,11 @@ static __must_check struct vm_area_struct *vma_merge_existing_range(
 	 * If we need to remove middle in its entirety but are unable to do so,
 	 * we have no sensible recourse but to abort the merge.
 	 */
-	if (vmg->__remove_middle && !can_merge_remove_vma(middle))
+	if (vmg->__remove_middle && !can_merge_remove_vma(middle)) {
+		vma_iter_set(vmg->vmi, start);
+		vma_iter_load(vmg->vmi);
 		return NULL;
+	}
 
 	/* If middle isn't removed then it's resized, i.e. splits. */
 	if (!vmg->__remove_middle && check_split(middle, left_side ? end : start))
diff --git a/tools/testing/vma/tests/merge.c b/tools/testing/vma/tests/merge.c
index b26f1a66a17074775d751a907eb627445cc1dda3..91accb5dc9944724cd11d1bfa47484a3cf9df54c 100644
--- a/tools/testing/vma/tests/merge.c
+++ b/tools/testing/vma/tests/merge.c
@@ -680,6 +680,7 @@ static bool test_vma_merge_with_close(void)
 	 */
 	ASSERT_EQ(merge_existing(&vmg), NULL);
 	ASSERT_EQ(vmg.state, VMA_MERGE_NOMERGE);
+	ASSERT_EQ(vma_iter_addr(&vmi), 0x3000);
 
 	ASSERT_EQ(cleanup_mm(&mm, &vmi), 2);
 

base-commit: 84abb955b1015477aa11a96e2f3ac1b938b77f48
-- 
2.43.0

Re: [PATCH] mm/vma: restore VMA iterator on full-range merge failure

[Lorenzo Stoakes (ARM)]

On Sun, Nov 15, 2026 at 12:46:55AM +0800, shao.mingyin@zte.com.cn wrote:
> From: Shao Mingyin <shao.mingyin@zte.com.cn>
>
> mm/vma: restore VMA iterator on full-range merge failure
>
> vma_merge_existing_range() moves the iterator to the previous VMA when
> merging to the left. If the range spans the whole middle VMA and a
> vm_ops->close() hook prevents removing it, the function returns without
> restoring the iterator.
>
> An mprotect() walk can then visit the middle VMA again. Restore the
> iterator to the range start, as the abort path already does. Extend the
> existing close-hook merge test to check the iterator after this failure.
> No crash or data corruption has been observed in this case.
>
> Fixes: 01c373e9a5ce2 ("mm: rework vm_ops->close() handling on VMA merge")
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>

(Not the first time I've seen this 'issue' reported).

This is pointless. No caller cares that the merge doesn't
proceed. Revisting it is a noop.

So this isn't a bug and the 'fix' achieves nothing except unnecessary
additional work.

I might go change how this behaves just to stop AI-generated reports... :)

> ---
> Tested with tools/testing/vma using its default ASan/UBSan options.
> The added iterator assertion fails before the fix; all 29 tests pass
> with the fix. Also build-tested mm/vma.o with W=1 on x86_64.
> This verifies iterator position, not a crash or a production workload.

Generally we expect people to mention their LLM usage here.

>
>
>  mm/vma.c                        | 5 ++++-
>  tools/testing/vma/tests/merge.c | 1 +
>  2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/mm/vma.c b/mm/vma.c
> index c82e9306b11ac14f684f44b8d71a0026b7fc145c..c87b29f1beec4ceb02c23f6b37af0e5dff272436 100644
> --- a/mm/vma.c
> +++ b/mm/vma.c
> @@ -983,8 +983,11 @@ static __must_check struct vm_area_struct *vma_merge_existing_range(
>  	 * If we need to remove middle in its entirety but are unable to do so,
>  	 * we have no sensible recourse but to abort the merge.
>  	 */
> -	if (vmg->__remove_middle && !can_merge_remove_vma(middle))
> +	if (vmg->__remove_middle && !can_merge_remove_vma(middle)) {
> +		vma_iter_set(vmg->vmi, start);
> +		vma_iter_load(vmg->vmi);
>  		return NULL;
> +	}
>
>  	/* If middle isn't removed then it's resized, i.e. splits. */
>  	if (!vmg->__remove_middle && check_split(middle, left_side ? end : start))
> diff --git a/tools/testing/vma/tests/merge.c b/tools/testing/vma/tests/merge.c
> index b26f1a66a17074775d751a907eb627445cc1dda3..91accb5dc9944724cd11d1bfa47484a3cf9df54c 100644
> --- a/tools/testing/vma/tests/merge.c
> +++ b/tools/testing/vma/tests/merge.c
> @@ -680,6 +680,7 @@ static bool test_vma_merge_with_close(void)
>  	 */
>  	ASSERT_EQ(merge_existing(&vmg), NULL);
>  	ASSERT_EQ(vmg.state, VMA_MERGE_NOMERGE);
> +	ASSERT_EQ(vma_iter_addr(&vmi), 0x3000);
>
>  	ASSERT_EQ(cleanup_mm(&mm, &vmi), 2);
>
>
> base-commit: 84abb955b1015477aa11a96e2f3ac1b938b77f48
> --
> 2.43.0

--
Cheers, Lorenzo

Re: [PATCH] mm/vma: restore VMA iterator on full-range merge failure

[shao.mingyin]

Hi Lorenzo,

Thank you for taking the time to review these patches. I am sorry for
interrupting your work and for the unnecessary review effort caused by
the iterator report.

I checked the mprotect() caller again. You are right: when the VMA is
revisited, its flags have already been updated and mprotect_fixup()
returns without changing them again. My added assertion established an
iterator position change, not a functional failure. I have withdrawn
that patch.

Since you also raised the breadth of my submissions in the related
threads (https://lore.kernel.org/all/avibe0HG4ssUUuBX@gremlin/), I
checked my submission records to provide some per-subsystem context.
Below are selected subsystems with recorded Reviewed-by or Applied
outcomes through 14 November (UTC+8). Patches first submitted on
15 November are excluded. Each distinct patch is counted once, including
fixes and cleanups; revisions, resends, cover letters and discussion
replies are not counted again.

Subsystem                 Sent  Reviewed-by  Applied  Withdrawn
NVMe/nvmet                  19           11        7          0
UBIFS                       12            6        0          0
ATA                         18            5        7          1
GPIO                         5            3        0          1
target                       8            2        5          0
SCSI                         9            2        3          1
ublk                         5            2        0          0
PCI                          5            1        1          0
MFD                          7            1        0          0
ALSA/ASoC                    5            0        5          0
SPI                          5            0        5          0

"Reviewed-by" counts patches with that explicit review tag. "Applied"
means merged or explicitly applied by a maintainer. A patch can appear
in both columns. "Withdrawn" includes patches I withdrew after review.

For two concrete examples of accepted work:

https://git.kernel.org/linus/08a6572441a4e646c96c2b8d8ead9eea0e458332
https://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git/commit/?id=fe5988e8708e1d42cb844bd9ac8f0a51388061fc

The first fixes zone-append sector reporting in virtio-blk's polled
completion path; the second fixes a NULL dereference in target ALUA.
These independently reviewed or accepted fixes are why I believe
AI-assisted work can make useful contributions. I remain responsible
for understanding each report and for the correctness of each patch.

I would like to learn from the technical feedback and improve the
quality of my contributions. Thank you for any further guidance you
are willing to offer, and again, sorry for the interruption.

Thanks,
Shao

Re: [PATCH] mm/vma: restore VMA iterator on full-range merge failure

[Gregory Price (Meta)]

On 2026-11-15 02:58 +0800, shao.mingyin@zte.com.cn wrote:
> 
> I would like to learn from the technical feedback and improve the
> quality of my contributions. Thank you for any further guidance you
> are willing to offer, and again, sorry for the interruption.
> 

It's a matter of triage, attention, and respect for people's time.

If a bug is unreachable or so low impact that it has no appreciable
effect on in-tree code, mass-driveby submissions take maintainer
attention away from critical issues. That is a net-negative.

Exporting this triage (mental load) to maintainers creates a strain
on the humans in the loop.

By the time the patch / report is read, the damage is done.

Even reading your patch message, it's unclear to me what the iterator
position being off even means.  What visible effect does this have?
(None, it's not even obviously a bug).

You may ask why not pass the patch to an LLM to help automate that,
but then you are externalizing the token cost (and someone still has
to read the output).

This is not intended to put you down, just to illustrate the frustration
that these kinds of submissions is causing.

-- 
~Gregory

Re: [PATCH] mm/vma: restore VMA iterator on full-range merge failure

[shao.mingyin]

Gregory,

Thank you for the candid reply, and for taking the time to write it. I
appreciate that you explained the problem instead of just dismissing the
submission.

You are right about the triage cost. I had been treating an LLM-assisted
patch that gets applied as the measure of a useful contribution, and I
did not weigh the review time that every submission takes from
maintainers -- including the ones that are ultimately rejected. The VMA
iterator patch in this thread was exactly that kind of report: I could
show an internal invariant but not a user-visible effect, and the cost of
reading it was still real. I have withdrawn it.

I will change how I work before sending anything else. I will not submit
a patch until I can state a reachable trigger and a user-visible effect.
If I cannot establish that a report is worth your time, I will not send
it.

Thank you again for the honesty and the guidance. I will take it with me.

Thanks,
Shao

Re: [PATCH] mm/vma: restore VMA iterator on full-range merge failure

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Low] mm/vma: duplicated subject line in commit message body
--

commit 53321f02a2e2d093a67d34a87521909e373ff074
Author: Shao Mingyin <shao.mingyin@zte.com.cn>

> mm/vma: restore VMA iterator on full-range merge failure
>
> mm/vma: restore VMA iterator on full-range merge failure
>
> vma_merge_existing_range() moves the iterator to the previous VMA when
> merging to the left. If the range spans the whole middle VMA and a
> vm_ops->close() hook prevents removing it, the function returns without
> restoring the iterator.
>
> An mprotect() walk can then visit the middle VMA again. Restore the
> iterator to the range start, as the abort path already does. Extend the
> existing close-hook merge test to check the iterator after this failure.
> No crash or data corruption has been observed in this case.
>
> Fixes: 01c373e9a5ce2 ("mm: rework vm_ops->close() handling on VMA merge")
> Signed-off-by: Shao Mingyin <shao.mingyin@zte.com.cn>

[Severity: Low]
This isn't a bug, but the commit subject line is repeated at the start of
the commit message body.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261115004655564ix3vefI54RZ3HhYOmxuKX@zte.com.cn?part=1