Re: [PATCH 1/6] mm/selftests: Fix virtual_address_range test issues.

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

On Mon, Jun 16, 2025 at 09:57:10PM +0530, Dev Jain wrote:
>
> On 16/06/25 9:36 pm, Aboorva Devarajan wrote:
> > From: Donet Tom <donettom@linux.ibm.com>
> > 3./proc/self/maps may not always have gaps smaller than MAP_CHUNK_SIZE.
> > The gap between the first high address mapping and the previous mapping
> > is not smaller than MAP_CHUNK_SIZE.
>
> For this, can't we just elide the check when we cross the high boundary?
> As I see it you are essentially nullifying the purpose of validate_complete_va_space;
> I had written that function so as to have an alternate way of checking VA exhaustion
> without relying on mmap correctness in a circular way.
>
> Btw @Lorenzo, validate_complete_va_space was written by me as my first patch ever for
> the Linux kernel : ) from the limited knowledge I have of VMA stuff, I guess the

:)

Mine was this utter triviality, but got me started :>)

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e1da1d573f67d11c2f80ffaf38d3cdd3fee97d4b

> only requirement for VMA alignment is PAGE_SIZE in this test, therefore, the only
> check required is that the gap between two VMAs should be at least MAP_CHUNK_SIZE?
> Or can such a gap still exist even when the VA has been exhausted?

VMAs are mapped at page granularity, the logic as to placement is determined by
the get unmapped area logic, for instance mm_get_unmapped_area_vmflags().

Unless a compatibility flag is set it'll be determined top-down.

I try to avoid thinking about 32-bit kernels at all so meh to all that :)

You get arch-specific stuff in arch_get_unmapped_area_topdown().

But the generic shared stuff is in vm_unmapped_area(), typically,
unmapped_area_topdown().

TL;DR, aside from arch stuff, the stack guard gap is the main additional
requirement, which puts (by default) 256 pages between an expanding stack and
the start of a new mapping. Which is 1 GB :) which maybe is why you chose this
value for MAP_CHUNK_SIZE?

For shadow stack we also have a 4 KB requirement. But only on x86-64 :)

Anyway I'm not sure there's huge value in sort of writing a test that too
closely mimics the code it is testing. Setting broad expections (which I presume
this test does) is better.