Re: [PATCH] selftests/mm: remove virtual_address_range test

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Tue, Jan 20, 2026 at 10:59:01AM +0530, Dev Jain wrote:
>

> I'll reply to everything here otherwise I'll have to repeat myself at different places.
>
> "Also exhausting VA space is an inherently silly thing for a test to do, you're
> making assumptions about existing VMA layout which is absolutely an
> implementation detail and may even be influence by libc..."
>
> The original version only uses mmap() and checks whether we got a high address mmap
> success when we shouldn't have. There are no assumptions being made here about
> VA layout. No matter the VA layout, the test will succeed because the kernel
> must enforce the distinction between low and high addresses (but see point 3 below).
>
>
> "It is therefore ENTIRELY a user-facing and kernel/user API thing that has to be tested from this perspective."
>
> So in merge.c, the statements ASSERT_NE(ptrx, MAP_FAILED) surely assert the
> user-visible API - that mremap must not fail. But there are statements which
> also assert where a VMA starts and where it ends, testing VMA merging -
> I was concerned about these. It is not the goal of userspace to minimize the
> number of VMAs while making a syscall - that is a kernel optimization. My point being,
> I suspect that the mm selftests *already* test internal details a lot, and I believe
> that they *need* to! Running selftests is the most convenient way of testing the mm subsystem.
> Hence this should not be a ground for removal of test.

Dev I would rather try to be positive not negative in review but again,
this isn't constructive, we're not talking about merge.c and even if it
contained the comment /* Ha ha I am a contradiction */ it wouldn't impact
this discussion.

You're not correct, mremap() has an API requirement that you can't cross
VMA boundaries for most operations, therefore start/end of VMA's and
merging _does_ matter. This also impacts how e.g. madvise() behaves.

As I said before:

	But you do not - both VMA merge and CoW impact API. Re: merging
	certain user-facing functions, most notably mremap(), have API
	requirements that the user must not cross VMA boundaries. It is
	therefore ENTIRELY a user-facing and kernel/user API thing that has
	to be tested from this perspective.

Can we drop the subject please?

>
> Talking about the recent commits, they can be reverted. So, the ground for
> removal should be that the ratio of the time taken by the test (exhausting VA
> space), to the coverage of the test (for arm64, it is testing backward compatibility of 48-bit VA
> on 52-bit VA, which one can argue is easy to spot if it ever breaks, and easy to fix)
> is too large and does not justify a selftest. I tend to agree here.
>
> "Add a _new_ selftest, named something sensible like mmap_hint.c or something ..."
>
> va_high_addr_switch.c tests stuff around the switch boundary. But it does not
> exhaust VA space. We *must* exhaust VA space if we are to check that the kernel,
> in a situation of "emergency" (i.e exhausted lower VA space), starts giving out
> high addresses, when it shouldn't. Again, one may argue that trying to test
> this out is not worth it.
>
> I personally opine that besides testing the back compat of 48 bit VA on 52 bit VA,
> we are testing something more important here: exhausting the VA space tests whether
> the kernel can truly distinguish b/w virtual and physical memory - we stress the virtual
> memory subsystem without touching physical memory, something which the kernel should be able
> to handle. But again, any such test has the potential for a timeout. I wonder if there is a
> faster way of filling up VA space.
>
> To summarize, I will agree with you that currently
>
> 1. The test is in a broken state
> 2. The test is taking too much time to test something trivial
> 3. It is a maintenance hazard. It turns out that the original version used
>    MAP_CHUNK_SIZE of 16GB, but then it was changed to 1GB because (this is the bit
>    where the dependency on VA layout comes) on some systems even a single 16GB mmap
>    may fail. So now we are stuck in making a tradeoff between the size of a single
>    mmap versus the time taken by the test
>
> So the better option seems to just remove the test.

Right let's just focus on that.

>
> A separate question: Do you think that the functionality advertised by validate_complete_va_space,
> to check the gaps between VMAs, deserves a test in kunit / tools/testing/vma, or somewhere else?

I don't think so as it's not a requirement set in stone as far as I
understand it.

But expectations as to what get_unmapped_area() should be doing makes more
sense as a kunit test.

Thanks, Lorenzo