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
