Message-ID: <8acef9ff-c5e2-4111-9437-f50b427db061@lucifer.local>
Date: Tue, 20 Jan 2026 08:43:04 +0000
From: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
To: Dev Jain <dev.jain@....com>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
        David Hildenbrand <david@...nel.org>,
        "Liam R . Howlett" <Liam.Howlett@...cle.com>,
        Vlastimil Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>,
        Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
        linux-kernel@...r.kernel.org, linux-mm@...ck.org,
        linux-kselftest@...r.kernel.org, Mark Brown <broonie@...nel.org>,
        aneesh.kumar@...nel.org, Anshuman Khandual <anshuman.khandual@....com>
Subject: Re: [PATCH] selftests/mm: remove virtual_address_range test

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

Powered by blists - more mailing lists