To: Richard QinSubject: Re: Porting Linux VM tests to GNU Mach/Hurd — feedback
Hello Richard, Thanks for asking before starting — this is definitely a useful direction. VM regression coverage is one of the weaker spots in GNU Mach today, and the Linux mm selftests are the best corpus of battle- tested scenarios we could borrow from. Reusing the basic parent/child COW tests from tools/testing/selftests/mm/cow.c is a sensible first step. Some feedback on your questions: Integration: kernel test framework vs. user space.I'd suggest a two- tier approach, matching what each layer actually exercises: Tests that drive Mach VM interfaces directly (vm_map, vm_inherit, wiring, memory objects) belong in gnumach/tests, next to the existing test-vm.c. The COW semantics tests, however, are most valuable as user-space programs running on Hurd: they go through glibc (fork, mmap MAP_PRIVATE, mprotect, SIGSEGV handlers), which exercises the full path a real application uses, not just the microkernel in isolation. That is also the layer where regressions hurt users most. For a first patch, I'd start with the user-space variant of the basic COW tests, since cow.c's core scenarios (write-after-fork isolation, mprotect after fork, partial unmap) are largely POSIX-based and port cleanly. You will need to strip the Linux-specific machinery for the first iteration — userfaultfd, memfd, THP, /proc/self/mem, mremap behavior checks — and keep those as follow-ups where an equivalent exists or is worth implementing. Higher-priority VM tests, in rough order: COW isolation correctness after fork (the basics you picked), including refcount correctness on partial unmap/remap of COW regions. mprotect interplay with COW: permission downgrade/upgrade after fork, write-fault on a read-only COW mapping. Page-fault correctness and basic latency measurement, as a regression baseline. Map/unmap/mapping churn performance — extends what benchmarks/forks.c measures. Memory-object mapping and external pager behavior (partially covered by test-vm.c already) — worth consolidating rather than duplicating. Address-space limit enforcement, if not already covered. Licensing. Retaining the original GPL-2.0 notices and copyright headers as you propose is the right approach. Since some selftests files are GPL-2.0-only, it's worth confirming placement with the maintainers before the first commit (user-space Hurd vs. gnumach/tests), but I don't expect it to be a blocker for the basic tests. So: yes, please go ahead with the small COW patch first, including build/run instructions and your results. Incremental expansion from there is much easier to review than one large drop. Best regards,Claire IvanenkaTo: Richard QinSubject: Re: Porting Linux VM tests to GNU Mach/Hurd — feedback Hello Richard, Thanks for asking before starting — this is definitely a useful direction. VM regression coverage is one of the weaker spots in GNU Mach today, and the Linux mm selftests are the best corpus of battle- tested scenarios we could borrow from. Reusing the basic parent/child COW tests from tools/testing/selftests/mm/cow.c is a sensible first step. Some feedback on your questions: Integration: kernel test framework vs. user space.I'd suggest a two- tier approach, matching what each layer actually exercises: Tests that drive Mach VM interfaces directly (vm_map, vm_inherit, wiring, memory objects) belong in gnumach/tests, next to the existing test-vm.c. The COW semantics tests, however, are most valuable as user-space programs running on Hurd: they go through glibc (fork, mmap MAP_PRIVATE, mprotect, SIGSEGV handlers), which exercises the full path a real application uses, not just the microkernel in isolation. That is also the layer where regressions hurt users most. For a first patch, I'd start with the user-space variant of the basic COW tests, since cow.c's core scenarios (write-after-fork isolation, mprotect after fork, partial unmap) are largely POSIX-based and port cleanly. You will need to strip the Linux-specific machinery for the first iteration — userfaultfd, memfd, THP, /proc/self/mem, mremap behavior checks — and keep those as follow-ups where an equivalent exists or is worth implementing. Higher-priority VM tests, in rough order: COW isolation correctness after fork (the basics you picked), including refcount correctness on partial unmap/remap of COW regions. mprotect interplay with COW: permission downgrade/upgrade after fork, write-fault on a read-only COW mapping. Page-fault correctness and basic latency measurement, as a regression baseline. Map/unmap/mapping churn performance — extends what benchmarks/forks.c measures. Memory-object mapping and external pager behavior (partially covered by test-vm.c already) — worth consolidating rather than duplicating. Address-space limit enforcement, if not already covered. Licensing. Retaining the original GPL-2.0 notices and copyright headers as you propose is the right approach. Since some selftests files are GPL-2.0-only, it's worth confirming placement with the maintainers before the first commit (user-space Hurd vs. gnumach/tests), but I don't expect it to be a blocker for the basic tests. So: yes, please go ahead with the small COW patch first, including build/run instructions and your results. Incremental expansion from there is much easier to review than one large drop. Best regards, Claire Ivanenka On Mon, 2026-10-12 at 02:25 +0800, Richard wrote: > Hello, > > I am considering porting selected Linux VM tests to GNU Mach/Hurd and > would like to ask for feedback before starting the work. > > I reviewed the existing gnumach/tests/test-vm.c and Hurd's > benchmarks/forks.c. > > The former mainly covers memory-object mapping, wiring, and VM > address-space limits. The latter measures fork/wait overhead. > I would like to add tests for COW isolation correctness, page faults, > and mapping performance, to provide regression coverage for future VM > changes. > > As a first step, I would select suitable tests from Linux's > tools/testing/selftests/mm, beginning with the basic parent/child COW > tests in cow.c. > > Any reused code would retain its applicable license and copyright > notices. > > Before submitting patches, I would like to know whether this > direction > is considered useful and whether the tests should be integrated into > GNU Mach's test framework or provided as user-space programs running > on > Hurd. > > Suggestions for higher-priority VM tests would also be welcome. > If this direction seems appropriate, I would first submit a small COW > test patch, together with instructions and results, and expand the > coverage incrementally. > > Thank you. > Richard Qin
