mm: nommu: point to the write iterator upon split_vma

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.

Quoted 3 lines · Andrew Morton

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)

Quoted 8 lines · On Mon, 6 Jul 2026 04:58:28 +0100 Matthew Wilcox <[email protected]> wrote:

Quoted 3 lines · Andrew Morton

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.

Quoted 6 lines

: 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?

Hi Andrew,

Quoted 19 lines · Andrew Morton

Quoted 8 lines · On Mon, 6 Jul 2026 04:58:28 +0100 Matthew Wilcox <[email protected]> wrote:

Quoted 3 lines · Andrew Morton

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.

Quoted 6 lines

: 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)

Quoted 1 line

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 -- [email protected]

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

Quoted 22 lines · Geert Uytterhoeven

Hi Andrew,

Quoted 19 lines · Andrew Morton

Quoted 8 lines · On Mon, 6 Jul 2026 04:58:28 +0100 Matthew Wilcox <[email protected]> wrote:

Quoted 3 lines · Andrew Morton

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.

Quoted 6 lines

: 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)

Quoted 8 lines

Quoted 1 line

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.

Quoted 35 lines · Lorenzo Stoakes

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.

Quoted 5 lines

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/[email protected]/
*2 https://lore.kernel.org/ltp/20240105131135.GA1484621@pevik/

-- Hajime

Quoted 2 lines

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.

Quoted 6 lines

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

I've struggled to even get the buildroot images to work in any way. Right now I don't have a clear nommu test setup other than building nommu_virt_defconfig for riscv.

Quoted 2 lines

# yes, should use ccache :)

:))

Quoted 5 lines

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.

Yeah.

Well indeed my raising the 'please let us pull this out' was initially a push back on that, because if we were going to pull it then that work would work against it, but then it became clear that that dream wasn't possible.

And that makes your work on that REALLY REALLY USEFUL :) so do cc me and ping me on any respin and I'll try to find time to help.

Quoted 4 lines

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.

Yeah and it's just the same thing overall with all of this.

The companies who are apparently dependent on this need to _actually pay people to do some even rudimentary testing_.

nommu.c is co-maintained by me and Liam simply because we have done more to fix issues with it than nearly anybody else recently. It's just a burden that we took on.

I'd far rather see an invested mm person take over if we do indeed have to live with it :)

I also wonder if we couldn't find a way to implement it in a more maintainable way, perhaps as a 'virtual' mmu system somehow?

I simply don't have the bandwidth for that myself, unfortunately.

Quoted 4 lines

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.

Your work is appreciated and welcome, thank you! :)

Quoted 2 lines

I hope this helps a bit.

You're definitely helping here and again, much appreciated!

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)

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/[email protected]