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/[email protected]/ > > >>> > > >>> 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
