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@xxxxxxxxxxxxxxxxxxxx> wrote:
> > > On Mon, 6 Jul 2026 04:58:28 +0100 Matthew Wilcox <willy@xxxxxxxxxxxxx> 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@xxxxxxxxx/
*2 https://lore.kernel.org/ltp/20240105131135.GA1484621@pevik/

-- Hajime