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

[Dev Jain <dev.jain@arm.com>]

On 18/06/25 4:52 pm, Lorenzo Stoakes wrote:
> 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?

MAP_CHUNK_SIZE was chosen randomly. Good to see it translates into something logical : )

So I guess I am correct, if we can find two VMAs (except at the edge of the high addr boundary)
with a gap of greater than MAP_CHUNK_SIZE then there is a bug in mmap().

>
> 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.