Re: [PATCH v2 0/2] support kselftest on nommu platform

[Hajime Tazaki <thehajime@gmail.com>]

Hello David, Lorenzo,

On Tue, 25 Aug 2026 23:28:24 +0900,
Lorenzo Stoakes (ARM) wrote:
> 
> On Tue, Aug 25, 2026 at 04:17:54PM +0200, David Hildenbrand (Arm) wrote:
> > On 8/25/26 15:12, Lorenzo Stoakes (ARM) wrote:
> > > On Tue, Aug 25, 2026 at 10:37:41AM +0200, David Hildenbrand (Arm) wrote:
> > >> On 8/25/26 03:59, Hajime Tazaki wrote:
> > >>> We add an ability to execute kselftest on 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.
> > >>>
> > >>> 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 is the lack of fork(2) syscall on those platforms.
> > >>> Especially the test harness helper (kselftest_harness.h) uses the
> > >>> syscall, which cannot be simply with vfork(2).  `timeout` command used
> > >>> in `runner.sh` never works for nommu platform as it uses fork(2).
> > >>>
> > >>> nommu component in the mm subsystem has several known issues and having
> > >>> test cases should help this situation, thus this patchset is very first
> > >>> step toward enriching test environment which has not been well tested
> > >>> for a while.  The test cases is implemented based on the document
> > >>> (Documentation/admin-guide/mm/nommu-mmap.rst).
> > >>>
> > >>> So, for the first step, nommu targets only support low-level API of
> > >>> kselftests (kselftest.h), and implement tests in a new target,
> > >>> TARGETS=mm/nommu.  Other targets are currently not even able to build
> > >>> due to toolchain issues but will be addressed once the initial
> > >>> introduction which mainly focuses on nommu test will be settled.
> > >>>
> > >>> The patch was initially combined with other patches but is decoupled to
> > >>> only focus on test framework and testcases.
> > >>>
> > >>> - rfc:
> > >>> https://lore.kernel.org/linux-mm/20260813063401.1786548-1-thehajime@gmail.com/
> > >>>
> > >>> Hajime Tazaki (2):
> > >>>   selftests: run tests on nommu architecture
> > >>>   selftests/mm: add nommu mmap and mremap behavior tests
> > >>>
> > >>>  Documentation/dev-tools/kselftest.rst         |  14 +
> > >>>  tools/testing/selftests/Makefile              |   1 +
> > >>>  tools/testing/selftests/kselftest/runner.sh   |   9 +-
> > >>>  tools/testing/selftests/kselftest_harness.h   |   4 +
> > >>>  tools/testing/selftests/lib.mk                |   8 +
> > >>>  tools/testing/selftests/mm/nommu/Makefile     |   7 +
> > >>>  .../selftests/mm/nommu/nommu_mmap_test.c      | 265 +++++++++++++
> > >>>  .../selftests/mm/nommu/nommu_mremap_test.c    | 353 ++++++++++++++++++
> > >>
> > >> That's odd.
> > >>
> > >> 	tools/testing/selftests/mm
> > >>
> > >> itself should know which tests can be built and ran on nommu. nommu-only tests
> > >> can be placed in mm/nommu, but I would expect tools/testing/selftests/mm's
> > >> Makefile and run script to compile and run only selftests that are supported on
> > >> the given platform.
> > >
> > > I mean I think at this point with mm/nommu/nommu_xxx.c it'd make more sense to
> > > simply have selftests/nommu/ + update the mm makefile to not build stuff that's
> > > broken on nommu there.
> > >
> > > That way positively nommu-stuff is put in its own place and what's broken on mm
> > > specific to nommu can be fixed there.
> > >
> > > I'd rather isolate them clearly rather than having them live in a subdirectory
> > > of mm.
> >
> > My understanding is that some MM tests could be enabled/changed in the future
> > that support both MMU and NOMMU. Not sure how to best handle that.
> 
> Well by default won't everything run? And it becomes a list of what doesn't
> work with nommu?
> 
> I really don't want to see any maintainership burden or extra work added
> for nommu as it's afaic deprecated.
> 
> >
> > So wiring up mm/nommu as a separate thing did sound wrong to me. So it should
> > either be integrated or the tests in fact completely moved out of mm/
> 
> Not integrated, because then it starts adding work for people. I'd rather
> have separate nommu tests, any mm tests that aren't compatible with nommu
> can just be somehow excluded.
> 
> Having a 'don't run on nommu' or even just some means of setting which
> tests to skip (I think Mark Brown suggested as much in reply to an earlier
> version of the series) seems a good idea.
> 
> But yeah, tools/testing/selftests/nommu seems the best place for the
> nommu-specific stuff.
> 
> Can maybe do some ../mm/ horror show thing for reducing duplication as
> needed...

As David mentioned my goal is to run all selftests/mm tests on nommu,
but as I explained situation to Lorenzo, it currently doesn't any
tests of mm/ on nommu platform (plus cannot build).

so I'd like to start as minimum as possible for this patchset, thus
creating different TARGET at mm/nommu, which I thought it should no
harm to the parent directory.

But I can move from selftests/mm/nommu to selftests/nommu for now, and
will propose to move into mm/nommu once it will be more meaningful to
do so.

# btw, I started to looking at code toward virtual mmu; I cannot tell
  how it'll be tho now.

-- Hajime