[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <815793f1-6800-4b9a-852e-f13d6308f50f@arm.com>
Date: Wed, 18 Jun 2025 19:47:18 +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 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.
>
> 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 : )
Powered by blists - more mailing lists