linux-kernel - Re: [PATCH 1/6] mm/selftests: Fix virtual_address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <41d9a70d-9791-4212-af23-5b13d8e4a47d@arm.com>
Date: Wed, 18 Jun 2025 20:13:54 +0530
From: Dev Jain <dev.jain@....com>
To: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
Cc: Aboorva Devarajan <aboorvad@...ux.ibm.com>, akpm@...ux-foundation.org,
 Liam.Howlett@...cle.com, shuah@...nel.org, pfalcato@...e.de,
 david@...hat.com, ziy@...dia.com, baolin.wang@...ux.alibaba.com,
 npache@...hat.com, ryan.roberts@....com, baohua@...nel.org,
 linux-mm@...ck.org, linux-kselftest@...r.kernel.org,
 linux-kernel@...r.kernel.org, donettom@...ux.ibm.com, ritesh.list@...il.com
Subject: Re: [PATCH 1/6] mm/selftests: Fix virtual_address_range test issues.


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?