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

["David Hildenbrand (Arm)" <david@kernel.org>]

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.

> 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.

-- 
Cheers,

David