On 4/13/26 23:54, [email protected] wrote: > > On 4/13/26 12:46 PM, David Hildenbrand (Arm) wrote: >>> It's correct though mlock2 would also work since it's been in glibc for >>> several years now. I just matched the existing tests. mlock2_ is a >>> simple wrapper around syscall in tools/testing/selftests/mm/mlock2.h, >>> and it was introduced when the mlock2 syscall was introduced. A trailing >>> rather than a preceding underscore is...unfortunate. >> Interesting ... and confusing :) >> >>> >>> The intent was to skip the tests if compiled with headers where >>> MAP_DROPPABLE isn't defined rather than force the value and get EINVAL >>> because the kernel doesn't know about it. This way EINVAL can be flagged >>> as a test failure and not skipped since it would likely indicate a test >>> or kernel bug. >> Note that the kernel headers you are compiling against don't imply >> anything about the kernel that is actually running! So the argument >> regarding EINVAL doesn't really hold. > > Yes, I see that now. > > >> >> But note that we, in general, try to compile against the in-tree headers. >> >> See >> >> commit 75d60eb30daafb966db0e45f38e4cdeb5e5ed79c >> Author: Lorenzo Stoakes <[email protected]> >> Date: Mon Oct 28 14:13:30 2024 +0000 >> >> tools: testing: update tools UAPI header for mman-common.h >> >> Import the new MADV_GUARD_INSTALL/REMOVE madvise flags. >> >> And looking into it, I already see MAP_DROPPABLE there as well, so is >> any special handling here even needed? >> > I'd say no special handling is needed.
Right, so the #ifdef is not required at all. > If this test is compiled on with > a kernel that has MAP_DROPPABLE but run on an older kernel without > MAP_DROPPABLE, should it fail? Or should it interpret the EINVAL as a > sufficient reason to assume MAP_DROPPABLE is not supported and to skip > the result? My current thinking is it should fail because the EINVAL > could have another cause. Ah, you want to sense for MAP_DROPPABLE support in older kernels. I guess treating -EINVAL as "not supported on old kernel" is good enough. Looking at tools/testing/selftests/mm/droppable.c, we seem to not perform any such checks ... unfortunately. -- Cheers, David
