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

[Dev Jain]

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?