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

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

On 18/06/25 8:05 pm, Lorenzo Stoakes wrote:
> On Wed, Jun 18, 2025 at 07:47:18PM +0530, Dev Jain wrote:
>> On 18/06/25 7:37 pm, Lorenzo Stoakes wrote:
>>> On Wed, Jun 18, 2025 at 07:28:16PM +0530, Dev Jain wrote:
>>>> On 18/06/25 5:27 pm, Lorenzo Stoakes wrote:
>>>>> On Wed, Jun 18, 2025 at 05:15:50PM +0530, Dev Jain wrote:
>>>>> Are you accounting for sys.max_map_count? If not, then you'll be hitting that
>>>>> first.
>>>> run_vmtests.sh will run the test in overcommit mode so that won't be an issue.
>>> Umm, what? You mean overcommit all mode, and that has no bearing on the max
>>> mapping count check.
>>>
>>> In do_mmap():
>>>
>>> 	/* Too many mappings? */
>>> 	if (mm->map_count > sysctl_max_map_count)
>>> 		return -ENOMEM;
>>>
>>>
>>> As well as numerous other checks in mm/vma.c.
>> Ah sorry, didn't look at the code properly just assumed that overcommit_always meant overriding
>> this.
> No problem! It's hard to be aware of everything in mm :)
>
>>> I'm not sure why an overcommit toggle is even necessary when you could use
>>> MAP_NORESERVE or simply map PROT_NONE to avoid the OVERCOMMIT_GUESS limits?
>>>
>>> I'm pretty confused as to what this test is really achieving honestly. This
>>> isn't a useful way of asserting mmap() behaviour as far as I can tell.
>> Well, seems like a useful way to me at least : ) Not sure if you are in the mood
>> to discuss that but if you'd like me to explain from start to end what the test
>> is doing, I can do that : )
>>
> I just don't have time right now, I guess I'll have to come back to it
> later... it's not the end of the world for it to be iffy in my view as long as
> it passes, but it might just not be of great value.
>
> Philosophically I'd rather we didn't assert internal implementation details like
> where we place mappings in userland memory. At no point do we promise to not
> leave larger gaps if we feel like it :)

You have a fair point. Anyhow a debate for another day.

>
> I'm guessing, reading more, the _real_ test here is some mathematical assertion
> about layout from HIGH_ADDR_SHIFT -> end of address space when using hints.
>
> But again I'm not sure that achieves much and again also is asserting internal
> implementation details.
>
> Correct behaviour of this kind of thing probably better belongs to tests in the
> userland VMA testing I'd say.
>
> Sorry I don't mean to do down work you've done before, just giving an honest
> technical appraisal!

Nah, it will be rather hilarious to see it all go down the drain xD

>
> Anyway don't let this block work to fix the test if it's failing. We can revisit
> this later.

Sure. @Aboorva and Donet, I still believe that the correct approach is to elide
the gap check at the crossing boundary. What do you think?