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

[Hajime Tazaki <thehajime@gmail.com>]

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.

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,
-- Hajime