Re: [PATCH v4 1/2] selftests: run tests on nommu architecture

[Hajime Tazaki <thehajime@gmail.com>]

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