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

[Hajime Tazaki <thehajime@gmail.com>]

On Fri, 14 Aug 2026 22:02:21 +0900,
Lorenzo Stoakes (ARM) wrote:
> 
> 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
> > > > <gregkh@linuxfoundation.org> 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.

indeed, agree.

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

yes, I also encountered an issue involving maple tree on nommu (with
some crash of UML), and initially it was not really sure what was
going on.  It was not an issue of maple-tree itself but the usage of
it was not correct.

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

I still understand your pains.

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

I agree.

I wish that having public test cases would motivate other people to
fix/improve/extend code (because his/her patch has less regressions),
to make this initial attempt useful for broader audience.

So initially this is just a one-man contribution, and I also think
it's not sufficient, but I'm always motivated (and assumed) that an
initial contribution could open the doors to the any other people.

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

for this /dev/zero patch in a current shape, I agree.

for other fixes to the shrink/split flaws, I will try to improve it to
let less overhead to maintain (by addressing your comments).

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

ah, I also have thought about that.

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

Indeed, an emulation of mmu would be one promising direction.
I would like to spend more time to compare other alternatives for this
goal (which might not be a trivial hack).

-- Hajime