[PATCH v4 1/2] selftests: run tests on nommu architecture
Hajime Tazaki
thehajime at gmail.com
Thu Oct 1 19:38:51 PDT 2026
David, Lorenzo, Johannes,
thanks for the comments and inputs.
On Thu, 01 Oct 2026 19:01:45 +0900,
Johannes Berg wrote:
> > > $ make ARCH=um NOMMU=1 O=build kselftest-all TARGETS=nommu
> > > > $ make ARCH=um NOMMU=1 O=build kselftest-install TARGETS=nommu
> > > > $ NOMMU=1 ./build/kselftest/kselftest_install/run_kselftest.sh -p \
> > > > -c nommu
> > >
> > > Is there a way we could derive that from the environment in one of these cases?
> >
> > I thought maybe uname could help but our LLM overlords tell me no.
>
> Hajime originally wanted uname to indicate it, but that caused
> regressions elsewhere, so we dropped that commit. I guess we could put
> _something_ back?
systemd uses uname information and our (old) patch changing the format
triggered the regression. thus, we dropped it.
> > It pointed at something though.
> >
> > In fs/proc/meminfo.c:
> >
> > #ifndef CONFIG_MMU
> > show_val_kb(m, "MmapCopy: ",
> > (unsigned long)atomic_long_read(&mmap_pages_allocated));
> > #endif
> >
> > So MmapCopy in /proc/meminfo tells us definitively, weirdly enough.
>
> Hyrum's law and all that, but I guess it's not highly likely to (want
> to) change :)
a runtime detection is nice.
scanning /proc/meminfo might be useful. although it requires to mount
procfs (we can actually skip procfs mount as it is optional) so, this
is not 100% portable.
checking ENOSYS like syscall(SYS_mprotect) might be useful but I
wasn't sure if this is always the case of NOMMU or not.
My original attempt was to use include/generated/autoconf.h; with that
we can omit environmental variable or command argument of NOMMU=1,
but gave up with handling standalone build/test case which might miss
the generated file (and complicate the patch only for the NOMMU
detection).
So, specifying NOMMU=1 is my previous, though dirty, conclusion.
-- Hajime
More information about the linux-um
mailing list