Re: [RFC PATCH 0/6] fix nommu mmap and add nommu kselftests

Hello,

thank you for your time looking at this series.

On Fri, 14 Aug 2026 20:24:57 +0900,
Lorenzo Stoakes (ARM) wrote:
> 
> Note on procedure - please do just cc- everybody on everything. It's a
> total pain to pull down series

I understand, I'll do this way for future patches.

> On Thu, Aug 13, 2026 at 03:33:55PM +0900, Hajime Tazaki wrote:
> > This patchset fixes several issues on nommu mmap, munmap, and mremap
> > syscalls and add test cases on kselftests framework, which currently not
> > runnable on nommu platform.
> >
> > Fixes for nommu is to correctly handle error cases when vma shrink
> > happens, and add calling .mmap_prepare callback on private mapping
> > requests to fix the issue which we cannot MAP_PRIVATE /dev/zero file.
> >
> > One thing that I'd like to broadly ask you (thus this marks as RFC) is:
> > this fix contains a dirty check of /dev/zero using device type number.
> > Since mmap_zero_prepare() should be called before actual mapping, but
> > some of the .mmap_prepare handler should be called _after_
> > determine_vm_flags() as the .mmap_prepare handler checks the shared
> > flags, we cannot use vma_is_anonymous() in determine_vm_flags() to
> > check the file is /dev/zero or not.  So we introduced
> > is_file_anonymous() for that purpose, which I'd like to ask your inputs.
> 
> Yeah I have plans for /dev/zero which will make it truly anon soon enough
> :)
> 
> And I definitely do not want a predicate that tests for just this edge
> case.

It's good to know your /dev/zero plan, and yes, I would wait for it
before moving forward with this dirty approach.

> > And we add test cases to introduce kselftest for nommu platforms.
> >
> > Currently there are several issues if we wish to run kselftests on nommu
> > targets:
> >
> > - it cannot compile/build test binaries because the current files mainly
> >   assume to build with glibc,
> > - some of the tests are not able to run on nommu targets as there are no
> >   fork(2) syscall.
> 
> Let's fix things only where it's not too invasive.
> 
> >
> > The first issue can be avoided if we can build static PIE binaries (if
> > targets support it), but in our case (build on ubuntu/glibc and run on
> > alpine/musl-libc), it fails to invoke due to lack of the GNU ifunc
> > mechanism.  Thus, we need to cross-compile with musl toolchain, which
> > needs to be solved the first issue.
> >
> > The second issue can be simply avoided, at a glance, by globally
> > replacing the symbol `fork` with `vfork`, which is available on nommu
> > targets.  Especially the test harness helper (kselftest_harness.h) uses
> > fork(2).  But the issue is not simple: for instance, in vfork(2) case
> 
> No please don't do this, nommu is the odd one out and the tests should be
> targeted at the normal case.
> 
> vfork() has entirely different semantics than fork() and we need to assert
> fork() behaviour, not vfork() behaviour.
> 
> (Honestly it's completely bizarre that we support a version of linux that
> can't fork() in 2026)

I understand your concern on fork-less kernel.

I am aware of some of experimental work which try to introduce fork(2)
(or alike) features into nommu (or alike) kernels (links below).  some
of them require a CPU features, some of them gave up CoW, etc.  I
haven't really look into details but if these effort contain a
meaningful insight to implement in Linux mainline, I would spend more
time to study these in order to fill the current gaps between current
MMU and !MMU.

# of course this might be a surgery and should be in a long-term
  milestone, not coming very soon.

https://github.com/flexcap-project/ufork
https://sigops.org/s/conferences/hotos/2025/slides/slides414.pdf

> > parent process has to wait until children has done jobs, parent and
> > children share the memory and children may corrupt parent memory which
> > is never happened with fork(2) syscall.  `timeout` command used in
> > `runner.sh` never works for nommu platform as it uses fork(2).
> 
> Yup again this speaks to the surreal craziness of linux supporting nommu at
> all :)

ditto.

> >
> > Additionally, the lack of test cases for nommu environment will (or
> > already) become serious issues to maintain the codebase in the future.
> 
> But this has to be weighed against the maintenance headache of supporting
> nommu stuff.
> 
> It's not right for it to force everybody writing tests to have to think
> about it.

My design goal, for this nommu support on kselftest, is not like this;
preserve the way the current users (of kselftest) do, and everybody
doesn't have to care about the particular nommu case.

So if this series breaks this intention, it's a fail and I should fix
it to not affecting existing models.

> And already in the thread there's been discussion about a serious bug in
> 5.10 that nobody reported for _years_.
> 
> So testing stuff sure - but right now people (apart from you of course!)
> aren't even doing boot testing against mainline AFAICT, let alone running
> self-tests.
> 
> So I want the minimal changes that are not invasive and limited to nommu
> only as much as possible, please.

I understand.

For the next step, I would break up this series into at least 3
different series:

- split_vma fixes (may break into several patches)
- kselftest extension for nommu (also several patches)
- /dev/zero fix (will wait for your updates)

thanks again,

-- Hajime