From: "David Hildenbrand (Arm)" <david@kernel.org>
To: anthony.yznaga@oracle.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org
Cc: akpm@linux-foundation.org, ljs@kernel.org,
Liam.Howlett@oracle.com, vbabka@kernel.org, rppt@kernel.org,
surenb@google.com, mhocko@suse.com, jannh@google.com,
pfalcato@suse.de, Jason@zx2c4.com, shuah@kernel.org
Subject: Re: [PATCH v3 2/2] selftests/mm: verify droppable mappings cannot be locked
Date: Mon, 13 Apr 2026 21:46:28 +0200 [thread overview]
Message-ID: <b579517c-e739-4db5-ab0b-4db3d579807c@kernel.org> (raw)
In-Reply-To: <38fd3d86-f080-4b3a-a931-8ddae1a420ae@oracle.com>
>>
>>> + if (munlockall()) {
>>> + ksft_test_result_fail("munlockall() %s\n", strerror(errno));
>>> + return;
>>> + }
>>> +
>>> + map = mmap(NULL, 2 * page_size, PROT_READ | PROT_WRITE,
>>> + MAP_ANONYMOUS | MAP_DROPPABLE, -1, 0);
>>> + if (map == MAP_FAILED) {
>>> + if (errno == EOPNOTSUPP)
>>> + ksft_test_result_skip("%s: MAP_DROPPABLE not
>>> supported\n", __func__);
>>> + else
>>> + ksft_test_result_fail("mmap error: %s\n", strerror(errno));
>>> + return;
>>> + }
>>> +
>>> + if (mlock2_(map, 2 * page_size, 0))
>> Weird, is "mlock2_" actually correct? (not "mlock2") ?
>
> 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 :)
>
>
>>
>>> + ksft_test_result_fail("mlock2(0): %s\n", strerror(errno));
>>> + else
>>> + ksft_test_result(!unlock_lock_check(map, false),
>>> + "%s: droppable memory not locked\n", __func__);
>>> +
>>> + munmap(map, 2 * page_size);
>>> +}
>>> +
>>> +static void test_mlockall_future_droppable(void)
>>> +{
>>> + char *map;
>>> + unsigned long page_size = getpagesize();
>>> +
>>> + if (mlockall(MCL_CURRENT | MCL_FUTURE)) {
>>> + ksft_test_result_fail("mlockall(MCL_CURRENT | MCL_FUTURE):
>>> %s\n", strerror(errno));
>>> + return;
>>> + }
>>> +
>>> + map = mmap(NULL, 2 * page_size, PROT_READ | PROT_WRITE,
>>> + MAP_ANONYMOUS | MAP_DROPPABLE, -1, 0);
>>> +
>>> + if (map == MAP_FAILED) {
>>> + if (errno == EOPNOTSUPP)
>>> + ksft_test_result_skip("%s: MAP_DROPPABLE not
>>> supported\n", __func__);
>>> + else
>>> + ksft_test_result_fail("mmap error: %s\n", strerror(errno));
>>> + munlockall();
>>> + return;
>>> + }
>>> +
>>> + ksft_test_result(!unlock_lock_check(map, false), "%s: droppable
>>> memory not locked\n",
>>> + __func__);
>>> +
>>> + munlockall();
>>> munmap(map, 2 * page_size);
>>> }
>>> +#else
>>> +static void test_mlock_droppable(void)
>>> +{
>>> + ksft_test_result_skip("%s: MAP_DROPPABLE not supported\n",
>>> __func__);
>>> +}
>>> +
>>> +static void test_mlockall_future_droppable(void)
>>> +{
>>> + ksft_test_result_skip("%s: MAP_DROPPABLE not supported\n",
>>> __func__);
>>> +}
>>> +#endif /* MAP_DROPPABLE */
>>>
>> Why not a above a
>>
>> #ifndef MAP_DROPPABLE
>> #define MAP_DROPPABLE 0x08
>> #endif
>>
>> instead?
>
> 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.
But note that we, in general, try to compile against the in-tree headers.
See
commit 75d60eb30daafb966db0e45f38e4cdeb5e5ed79c
Author: Lorenzo Stoakes <ljs@kernel.org>
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?
--
Cheers,
David
next prev parent reply other threads:[~2026-04-13 19:46 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-09 23:49 [PATCH v3 0/2] fix MAP_DROPPABLE not supported errno Anthony Yznaga
2026-04-09 23:49 ` [PATCH v3 1/2] mm: fix mmap errno value when MAP_DROPPABLE is not supported Anthony Yznaga
2026-04-09 23:49 ` [PATCH v3 2/2] selftests/mm: verify droppable mappings cannot be locked Anthony Yznaga
2026-04-10 7:57 ` David Hildenbrand (Arm)
2026-04-10 19:06 ` anthony.yznaga
2026-04-13 19:46 ` David Hildenbrand (Arm) [this message]
2026-04-13 21:54 ` anthony.yznaga
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b579517c-e739-4db5-ab0b-4db3d579807c@kernel.org \
--to=david@kernel.org \
--cc=Jason@zx2c4.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=anthony.yznaga@oracle.com \
--cc=jannh@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox