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

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

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

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo