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

["Lorenzo Stoakes (ARM)" <ljs@kernel.org>]

On Fri, Oct 02, 2026 at 08:08:44AM +0200, David Hildenbrand (Arm) wrote:
> On 10/2/26 04:38, Hajime Tazaki wrote:
> >
> > David, Lorenzo, Johannes,
> >
> > thanks for the comments and inputs.
> >
> > On Thu, 01 Oct 2026 19:01:45 +0900,
> > Johannes Berg wrote:
> >>>
> >>> 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.
> >
>
> I assume there are plenty of other mechanisms. Like testing if fork isn't allowed.

Yup that's an obvious candidate!

You actually need to check for both -EINVAL and -ENOSYS since, of course, we are
inconsistent with this.

Some nommu arches specify __ARCH_WANT_SYS_FORK unconditionally for both
mmu/nommu variants meaning you get -EINVAL in that case:

https://elixir.bootlin.com/linux/v7.2.8/source/kernel/fork.c#L2830

Otherwise you get -ENOSYS because it's not defined.

But fork() -> -EINVAL or -ENOSYS = nommu, then just have the child quit and
etc. should do it.

But then that'd need some C... ah fun :)

Crazy to me that we don't expose it in uname...

>
> > 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.
> Let's avoid making it harder on users by doing some runtime detection.

Yeah it'd be preferable.

I see a bunch of usage of procfs in selftests.

So can we just please require that the selftests have the user mount /proc, then
the /proc/meminfo grep is the easiest + quickest way.

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo