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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Thu, Aug 27, 2026 at 05:46:22PM +0900, Hajime Tazaki wrote:
>
> 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.

OK ack I will look for the respin! Thanks for the work on this!

Hopefully the push back is clear in that it's motivated by technical and
architectural concerns, your contributions are all appreciated and thank
you for doing the actual work rather than just talking about nommu, this is
great :)

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

Oh nice thanks :)

BTW did
https://lore.kernel.org/all/20260723093633.140989-12-johannes@sipsolutions.net/
go upstream? Or another UML nommu mode? I've not been keeping track of all
that.

>
> -- Hajime
>

--
Cheers, Lorenzo