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

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

[Hajime Tazaki]

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

Link:
https://github.com/linux-test-project/ltp/blob/master/testcases/kernel/syscalls/mseal/mseal02.c
Signed-off-by: Hajime Tazaki <thehajime@gmail.com>
---
 mm/nommu.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/mm/nommu.c b/mm/nommu.c
index ed3934bc2de4..5d461ddc3405 100644
--- 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;
 
-- 
2.43.0

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@gmail.com> 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@gmail.com

> --- 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.

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

[Matthew Wilcox]

On Sun, Jul 05, 2026 at 03:27:08PM -0700, Andrew Morton wrote:
> Thanks.  Unfortunately we aren't very diligent about the nommu code
> (are we?).   Perhaps appropriately - clearly this code doesn't get used a
> lot.

Should we delete support for NOMMU?  As you say, it doesn't get much
testing, or presumably usage.  I have this quote from #m68k a couple of
years ago...

: I looked at nommu very briefly when I had my 68000 board on the bench
: but didn’t get anywhere. Also didn’t try particularly hard. I think
: you are better off with fuzix or OS9 if you want something unixy.

(i suspect Zephyr would also be good, but it doesn't support m68k, just
arc, arm, arm64, mips, openrisc, renesas rx, riscv, sparc, x86 and xtensa)

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

[Andrew Morton]

On Mon, 6 Jul 2026 04:58:28 +0100 Matthew Wilcox <willy@infradead.org> wrote:

> On Sun, Jul 05, 2026 at 03:27:08PM -0700, Andrew Morton wrote:
> > Thanks.  Unfortunately we aren't very diligent about the nommu code
> > (are we?).   Perhaps appropriately - clearly this code doesn't get used a
> > lot.
> 
> Should we delete support for NOMMU?  As you say, it doesn't get much
> testing, or presumably usage.  I have this quote from #m68k a couple of
> years ago...

Greg is busily developing kernel code.

> : I looked at nommu very briefly when I had my 68000 board on the bench
> : but didn’t get anywhere. Also didn’t try particularly hard. I think
> : you are better off with fuzix or OS9 if you want something unixy.
> 
> (i suspect Zephyr would also be good, but it doesn't support m68k, just
> arc, arm, arm64, mips, openrisc, renesas rx, riscv, sparc, x86 and xtensa)

Greg, how mush use is NOMMU Linux seeing nowadays?

Thanks.

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

[Geert Uytterhoeven]

Hi Andrew,

On Mon, 6 Jul 2026 at 07:23, Andrew Morton <akpm@linux-foundation.org> wrote:
> On Mon, 6 Jul 2026 04:58:28 +0100 Matthew Wilcox <willy@infradead.org> wrote:
> > On Sun, Jul 05, 2026 at 03:27:08PM -0700, Andrew Morton wrote:
> > > Thanks.  Unfortunately we aren't very diligent about the nommu code
> > > (are we?).   Perhaps appropriately - clearly this code doesn't get used a
> > > lot.
> >
> > Should we delete support for NOMMU?  As you say, it doesn't get much
> > testing, or presumably usage.  I have this quote from #m68k a couple of
> > years ago...
>
> Greg is busily developing kernel code.
>
> > : I looked at nommu very briefly when I had my 68000 board on the bench
> > : but didn’t get anywhere. Also didn’t try particularly hard. I think
> > : you are better off with fuzix or OS9 if you want something unixy.
> >
> > (i suspect Zephyr would also be good, but it doesn't support m68k, just
> > arc, arm, arm64, mips, openrisc, renesas rx, riscv, sparc, x86 and xtensa)
>
> Greg, how mush use is NOMMU Linux seeing nowadays?

Nommu (SH-compatible J-Core ASIC) is used in actual products, running
modern kernels.  The rationale is low interrupt latency without using
a much more costly app CPU core + RT CPU core split.

Please watch the recording of the "32bit and-or noMMU Linux BoF"[1]
at LPC2025 for more info.

[1] https://lpc.events/event/19/contributions/2097/

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

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

[Lorenzo Stoakes]

On Mon, Jul 06, 2026 at 10:27:43AM +0200, Geert Uytterhoeven wrote:
> Hi Andrew,
>
> On Mon, 6 Jul 2026 at 07:23, Andrew Morton <akpm@linux-foundation.org> wrote:
> > On Mon, 6 Jul 2026 04:58:28 +0100 Matthew Wilcox <willy@infradead.org> wrote:
> > > On Sun, Jul 05, 2026 at 03:27:08PM -0700, Andrew Morton wrote:
> > > > Thanks.  Unfortunately we aren't very diligent about the nommu code
> > > > (are we?).   Perhaps appropriately - clearly this code doesn't get used a
> > > > lot.
> > >
> > > Should we delete support for NOMMU?  As you say, it doesn't get much
> > > testing, or presumably usage.  I have this quote from #m68k a couple of
> > > years ago...
> >
> > Greg is busily developing kernel code.
> >
> > > : I looked at nommu very briefly when I had my 68000 board on the bench
> > > : but didn’t get anywhere. Also didn’t try particularly hard. I think
> > > : you are better off with fuzix or OS9 if you want something unixy.
> > >
> > > (i suspect Zephyr would also be good, but it doesn't support m68k, just
> > > arc, arm, arm64, mips, openrisc, renesas rx, riscv, sparc, x86 and xtensa)
> >
> > Greg, how mush use is NOMMU Linux seeing nowadays?
>
> Nommu (SH-compatible J-Core ASIC) is used in actual products, running
> modern kernels.  The rationale is low interrupt latency without using
> a much more costly app CPU core + RT CPU core split.
>
> Please watch the recording of the "32bit and-or noMMU Linux BoF"[1]
> at LPC2025 for more info.

This crops up now and again and people point to uses, but fails to address the
real issue here.

Nobody (aside from Hajime - thank you!) who uses nommu maintains or contributes
to it, or _even tests_ it as far as I can tell.

We broken nommu for a year I think it was? And there wasn't one report.

The last time I raised this, I was admonished and told there are critical arm32
nommu devices that absolutely _must_ have the latest kernel and this is
perfectly working code.

And riscv also introduced (and I'm so very surprised Linus allowed it) a brand
new nommu architecture (!!)

And yet...

If this is really so important, can those who care perhaps help out a bit? At
least with testing?

I'm a bit fed up of it really.

As far as hobbyist retro stuff and upstream goes, I am sympathetic, I came from
being a hobbyist (though not retro), and would be one again if I couldn't do it
as a job.

But retro people do NOT need the latest kernel. As far as I'm concerned, museum
piece support should be ripped out, and those who care run downstream kernels.

As for the 'critical products' that must use nommu - PLEASE start
contributing. Please start testing. Anything.

Again thank you Hajime for doing the one thing that really counts here -
contributing to the nommu code.

Anyway, as to what Matthew said - 100% I am for us ripping it out.

But it's not up to me, and unfortunately I think we'll get a clammer of voices
saying how important it is, and silence again when it comes to do any of the
work.

>
> [1] https://lpc.events/event/19/contributions/2097/
>
> Gr{oetje,eeting}s,
>
>                         Geert
>
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
>
> In personal conversations with technical people, I call myself a hacker. But
> when I'm talking to journalists I just say "programmer" or something like that.
>                                 -- Linus Torvalds

Thanks, Lorenzo

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

[Hajime Tazaki]

On Mon, 06 Jul 2026 20:51:36 +0900,
Lorenzo Stoakes wrote:
> 
> On Mon, Jul 06, 2026 at 10:27:43AM +0200, Geert Uytterhoeven wrote:
> > Hi Andrew,
> >
> > On Mon, 6 Jul 2026 at 07:23, Andrew Morton <akpm@linux-foundation.org> wrote:
> > > On Mon, 6 Jul 2026 04:58:28 +0100 Matthew Wilcox <willy@infradead.org> wrote:
> > > > On Sun, Jul 05, 2026 at 03:27:08PM -0700, Andrew Morton wrote:
> > > > > Thanks.  Unfortunately we aren't very diligent about the nommu code
> > > > > (are we?).   Perhaps appropriately - clearly this code doesn't get used a
> > > > > lot.
> > > >
> > > > Should we delete support for NOMMU?  As you say, it doesn't get much
> > > > testing, or presumably usage.  I have this quote from #m68k a couple of
> > > > years ago...
> > >
> > > Greg is busily developing kernel code.
> > >
> > > > : I looked at nommu very briefly when I had my 68000 board on the bench
> > > > : but didn’t get anywhere. Also didn’t try particularly hard. I think
> > > > : you are better off with fuzix or OS9 if you want something unixy.
> > > >
> > > > (i suspect Zephyr would also be good, but it doesn't support m68k, just
> > > > arc, arm, arm64, mips, openrisc, renesas rx, riscv, sparc, x86 and xtensa)
> > >
> > > Greg, how mush use is NOMMU Linux seeing nowadays?
> >
> > Nommu (SH-compatible J-Core ASIC) is used in actual products, running
> > modern kernels.  The rationale is low interrupt latency without using
> > a much more costly app CPU core + RT CPU core split.
> >
> > Please watch the recording of the "32bit and-or noMMU Linux BoF"[1]
> > at LPC2025 for more info.
> 
> This crops up now and again and people point to uses, but fails to address the
> real issue here.
> 
> Nobody (aside from Hajime - thank you!) who uses nommu maintains or contributes
> to it, or _even tests_ it as far as I can tell.
> 
> We broken nommu for a year I think it was? And there wasn't one report.
> 
> The last time I raised this, I was admonished and told there are critical arm32
> nommu devices that absolutely _must_ have the latest kernel and this is
> perfectly working code.
> 
> And riscv also introduced (and I'm so very surprised Linus allowed it) a brand
> new nommu architecture (!!)
> 
> And yet...
> 
> If this is really so important, can those who care perhaps help out a bit? At
> least with testing?
> 
> I'm a bit fed up of it really.
> 
> As far as hobbyist retro stuff and upstream goes, I am sympathetic, I came from
> being a hobbyist (though not retro), and would be one again if I couldn't do it
> as a job.
> 
> But retro people do NOT need the latest kernel. As far as I'm concerned, museum
> piece support should be ripped out, and those who care run downstream kernels.
> 
> As for the 'critical products' that must use nommu - PLEASE start
> contributing. Please start testing. Anything.
> 
> Again thank you Hajime for doing the one thing that really counts here -
> contributing to the nommu code.
> 
> Anyway, as to what Matthew said - 100% I am for us ripping it out.
> 
> But it's not up to me, and unfortunately I think we'll get a clammer of voices
> saying how important it is, and silence again when it comes to do any of the
> work.

as nommu started for embedded devices which are not easy to test, I
agree that it is also not easy (in my opinion) to maintain.

indeed, buildroot images for nommu targets (with qemu) are available,
but running/testing each of commit to the kernel tree give me more
than 1 hour to rebuild the images (including userspace build with long
flat binary conversion, etc) (which I'm playing under github actions
with riscv-nommu).

# yes, should use ccache :)

one of the goal which I am with nommu UML (*1) is to provide an
environment which can be tested in a simple way; runs on x86
machines.  An extension to UML means that you can also use KUnit
infrastructure.

LTP (Linux Test Project) dropped the nommu tests 2 years ago (*2)
(which is pity), but the reason is similar: no maintainers appeared
when the project asked.

I wish to be here to improve this situation, both mm/nommu subsystem
and LTP, as well as any !CONFIG_MMU code in kernel tree.  This patch
is actually discovered during LTP (re-)integration with nommu kernel,
which I'm going to propose to LTP.

I hope this helps a bit.


*1 https://lore.kernel.org/all/cover.1770170302.git.thehajime@gmail.com/
*2 https://lore.kernel.org/ltp/20240105131135.GA1484621@pevik/

-- Hajime

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

[Daniel Palmer]

Hi Matthew,

On Mon, 6 Jul 2026 at 12:58, Matthew Wilcox <willy@infradead.org> wrote:
> Should we delete support for NOMMU?  As you say, it doesn't get much
> testing, or presumably usage.  I have this quote from #m68k a couple of
> years ago...
>
> : I looked at nommu very briefly when I had my 68000 board on the bench
> : but didn’t get anywhere. Also didn’t try particularly hard. I think
> : you are better off with fuzix or OS9 if you want something unixy.

There are a few of us using the 68000* port for hobby projects. After
hackernews saw that I got it running on a sega megadrive I got some
emails from people that are running a really old nommu arm fork on an
old mobile phone and are considering moving to mainline. I think there
are people using it in real world important stuff on riscv and superh.

I'm not demanding to keep it around for a few weird projects no one
cares about just saying we do exist. :)
I think most of us don't/won't notice mm stuff until something breaks our thing.
I have asked the ones I know about to at least send the patches they
have so people know there are users.

> (i suspect Zephyr would also be good, but it doesn't support m68k, just
> arc, arm, arm64, mips, openrisc, renesas rx, riscv, sparc, x86 and xtensa)

I think someone suggested this before but zephyr is really not as nice
as Linux to work with.
I have almost mainline linux, almost mainline u-boot etc running on
68000 with networking etc. It's even using devicetree.
I've been working on patches for nolibc for half a year so that it's
possible to create ELFs that run on mmu or nommu m68k instead of
porting something linux nuttx because the linux experience is just
better.

Thanks,

Daniel