Re: [PATCH] mm: nommu: point to the write iterator upon split_vma

[Andrew Morton]

On Thu,  2 Jul 2026 10:25:46 +0900 Hajime Tazaki <thehajime@xxxxxxxxx> wrote:

> When users munmap(2) the partial region allocated by mmap, it might
> split the original region if necessary and shrink to the right size.
> At the begining of vmi_shrink_vma(), it clears the unused part but
> generates assetion when the shrink happenes after split_vma().
> 
> This commit fixes this issue by configuring the right pointer to the
> iterator at the end of split_vma().
> 
> This was detected with a LTP (Linux Test Project) test, which linked
> below, on the nommu UML environment (out-of-tree extension to UML).
> 
> Here is a minimal reproducible chunk of code for this issue:
> 
> 	void *addr;
> 	size_t pagesize = getpagesize();
> 
> 	addr = mmap(NULL, pagesize * 4, PROT_READ | PROT_WRITE,
> 		    MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
> 	munmap(addr + pagesize * 1, pagesize);
> 
> This is the console output with CONFIG_DEBUG_MAPLE_TREE=y.
> 
> nommu: WARN at __mas_set_range:791 (1)
> MAS: tree=0000000091c23b08 enode=0000000065057663
> (ma_active)
> Store Type:
> node_store
> [9/9] index=70af8000 last=ffffffffffffffff
>      min=0 max=ffffffffffffffff sheaf=0000000000000000, request 0
> depth=0, flags=0
> maple_tree(0000000091c23b08) flags 307, height 1 root 0000000083394c06
> 0-ffffffffffffffff: node 0000000010c90bd6 depth 0 type 1 parent
> 0000000050e1ddf8 contents: 0000000000000000 707A
> 7FFF 00000000eb0ac2b5 707AFFFF 0000000000000000 7093FFFF
> 0000000045ead616 7095FFFF 0000000000000000 7096CFFF 000
> 00000681c7151 7096FFFF 0000000000000000 70AF3FFF 000000006c78b9e9
> 70AF4FFF 000000001914ab0b 70AF7FFF 00000000000
> 00000 FFFFFFFFFFFFFFFF 0000000000000000 0 0000000000000000 0
> 0000000000000000 0 0000000000000000 0 0000000000000
> 000 0 00000000bca8be4f
>   0-707a7fff: 0000000000000000
>   707a8000-707affff: 00000000eb0ac2b5
>   707b0000-7093ffff: 0000000000000000
>   70940000-7095ffff: 0000000045ead616
>   70960000-7096cfff: 0000000000000000
>   7096d000-7096ffff: 00000000681c7151
>   70970000-70af3fff: 0000000000000000
>   70af4000-70af4fff: 000000006c78b9e9
>   70af5000-70af7fff: 000000001914ab0b
>   70af8000-ffffffffffffffff: 0000000000000000
> nommu: Pass: 796 Run:797

Thanks.  Unfortunately we aren't very diligent about the nommu code
(are we?).   Perhaps appropriately - clearly this code doesn't get used a
lot.

It appears that AI review has found another issue in there:
	https://sashiko.dev/#/patchset/20260702012546.665383-1-thehajime@xxxxxxxxx

> --- a/mm/nommu.c
> +++ b/mm/nommu.c
> @@ -1367,6 +1367,10 @@ static int split_vma(struct vma_iterator *vmi, struct vm_area_struct *vma,
>  	setup_vma_to_mm(vma, mm);
>  	setup_vma_to_mm(new, mm);
>  	vma_iter_store_new(vmi, new);
> +
> +	/* vmi should point lower address */
> +	if (new_below)
> +		vma_next(vmi);
>  	mm->map_count++;
>  	return 0;

Lorenzo, others: do you have the time?  Thanks.