Re: [RFC PATCH 3/6] mm: nommu: fix an issue on map request to /dev/zero

On Fri, Aug 14, 2026 at 09:42:57PM +0900, Hajime Tazaki wrote:
>
> Hello Lorenzo,
>
> On Thu, 13 Aug 2026 22:29:38 +0900,
> Lorenzo Stoakes (ARM) wrote:
> >
> > On Thu, Aug 13, 2026 at 09:43:37PM +0900, Daniel Palmer wrote:
> > > Hi Greg,
> > >
> > > On Thu, 13 Aug 2026 at 21:26, Greg Kroah-Hartman
> > > <[email protected]> wrote:
> > >
> > > > Given the age of this issue, I don't think anyone uses no-mmu systems
> > > > anymore :(
> > >
> > > There are a few of us using it for hobby stuff[0][1] and there are
> > > apparently people using it for actual commercial stuff.
> > > There was a session about this at LPC 2025...
> > >
> > > One of the big problems for nommu seems to be that everyone is
> > > convinced it is completely unused and totally broken. :)
> >
> > No, the issue is that nobody seems to do any testing or contribute any code
> > aside from at least Hajime (thanks Haijme :), and possibly others (forgive me if
> > I am missing people's names here!)
> >
> > There's been situtions where nommu has been broken for a year and _nobody
> > noticed_.
> >
> > And yet whenever nommu comes up people always seem to pop up and say how
> > important it is, then mention a talk etc.
> >
> > Well if it's important, test it. Test the tip kernel. Report bugs. Contribute
> > code. Any or all of it :)
> >
> > Meanwhile we in mm have to _constantly_ fix stuff up in nommu because it's a
> > total mess and has real maintenance overhead.
> >
> > Having to account for legacy systems that make no sense in 2026 when you're
> > trying to make improvements to systems people use, or not being able to do
> > certain things, really grates after a while.
> >
> > I mean if you don't believe me git log mm/nommu.c. This overhead reason is why I
> > now co-maintain it.
>
> after spending more times to look at code, fixing issues, finding
> other flaws, etc, now I become to understand what you meant in past
> emails, when you're saying a more maintainable way of implementation
> of nommu.c.

Yes :)

Thanks for having some empathy about this :) It seems a lot of the nommu
advocates simply assume it's little or no overhead and is 'working
code'. No and no.

I know Liam had to do a _lot_ of work on maple tree to make things work
there, for instance.

And the recent VMA flags changes have had to be heavily updated to account
for nommu.

And the list goes on. New features have to touch it all the time to avoid
build failures even, and etc. etc.

It's a really absurd situation to be honest and the RoI isn't there at all.

There's a reason I keep going on about this :)

>
> Since I wish to use nommu.c in future with the latest kernel, I'd like
> to contribute it for, let's say, refactoring the nommu component which
> mm subsystem currently has.
>
> but for the moment, I wish to start with introducing test cases from
> very basic checks (which is in the [6/6] patch of this series).
> Without such a base, we may not have any chances to improve this nasty
> situation of nommu component in mm subsystem.
>
> # this motivation also applies to LTP (linux test project) which
>   currently doesn't support running tests on nommu platforms (I've
>   already started).
>
> And also as I mentioned before, ideally the code should be maintained
> by people who use it.  And if I claimed that I used/use/will use
> nommu.c, I wish to maintain this, or at least wish to help to decrease
> the overhead of maintainers.  This series is a very fist step toward
> this.
>
> I hope it clarifies a bit for your concerns,

Thanks, and I appreciate that you're actually doing work here, but I'm not
sure a single person suffices for this, as well intentioned as you are.

And as reviewed, these changes seem to be adding _more_ maintainership
overhead rather than less, I fear.

I believe nommu is pretty broken across many domains (it's fun to set
claude on it for instance).

And we've already spoken about broken things that have sat around for
a long time.

The way it's implemented now is just horrendous in any case, if we were
forced to keep it in the upstream kernel then the correct solution would be
something that somehow 'emulates' an mmu system.

But I'm not sure that's even workable, and likely implies heavy
maintainership headaches.

> -- Hajime
>

--
Cheers, Lorenzo