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

[David Hildenbrand (Arm)]

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.

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/

-- 
Cheers,

David