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

[Lorenzo Stoakes <ljs@kernel.org>]

On Mon, Jul 06, 2026 at 09:57:51PM +0900, Hajime Tazaki wrote:
> On Mon, 06 Jul 2026 20:51:36 +0900,
> Lorenzo Stoakes wrote:
> > 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.

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

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

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.

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

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

>
> I hope this helps a bit.

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

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

Cheers, Lorenzo