Re: [PATCH v2 2/2] selftests/mm: verify droppable mappings cannot be locked
From: anthony . yznaga
Date: Wed Apr 08 2026 - 18:26:44 EST
On 4/8/26 2:02 PM, Andrew Morton wrote:
On Wed, 8 Apr 2026 13:35:42 -0700 anthony.yznaga@xxxxxxxxxx wrote:That makes sense. It's trivial to skip the tests if MAP_DROPPABLE is not defined so I'll do that.
On 4/3/26 12:31 PM, Andrew Morton wrote:Cool.
On Thu, 2 Apr 2026 16:59:33 -0700 Anthony Yznaga <anthony.yznaga@xxxxxxxxxx> wrote:Interesting. Of the two issues, one is certainly legit. I need to add an
For configs that support MAP_DROPPABLE verify that a mapping createdThere are a few queries from the AI reviewbot;
with MAP_DROPPABLE cannot be locked via mlock(), and that it will not
be locked if it's created after mlockall(MCL_FUTURE).
https://sashiko.dev/#/patchset/20260402235933.10588-1-anthony.yznaga@xxxxxxxxxx
munlockall() on early return from test_mlockall_future_droppable().
For the other, the question posed was whether the tests should handleI don't know that there's any policy on that. My attitude is that
possibly being run on an older kernel that doesn't implement
MAP_DROPPABLE. It seems to me to that a selftest should not be expected
to work (or even necessarily compile) on kernels older than when the
selftest was introduced, but I don't want to assume.
selftests are not intended to be forward- or backward-compatible.
That's why we ship them with the kernel source!
If we get a selftests fixup then I do like to backport that into
earlier kernels if appropriate, to keep those in good shape. And that
has the effect of reducing people's motivation to run a later kernel's
selftests on their current kernel.