linux-kernel - Re: [PATCH v4 2/5] mm/selftests: add max_vma

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: <6c34ce4e-1212-4dd0-8b7c-6af952dda3cb@kernel.org>
Date: Mon, 3 Nov 2025 18:13:07 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Kalesh Singh <kaleshsingh@...gle.com>, akpm@...ux-foundation.org,
 minchan@...nel.org, lorenzo.stoakes@...cle.com, david@...hat.com,
 Liam.Howlett@...cle.com, rppt@...nel.org, pfalcato@...e.de
Cc: rostedt@...dmis.org, hughd@...gle.com, kernel-team@...roid.com,
 android-mm@...gle.com, Alexander Viro <viro@...iv.linux.org.uk>,
 Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>,
 Kees Cook <kees@...nel.org>, Vlastimil Babka <vbabka@...e.cz>,
 Suren Baghdasaryan <surenb@...gle.com>, Michal Hocko <mhocko@...e.com>,
 Jann Horn <jannh@...gle.com>, Masami Hiramatsu <mhiramat@...nel.org>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
 Ingo Molnar <mingo@...hat.com>, Peter Zijlstra <peterz@...radead.org>,
 Juri Lelli <juri.lelli@...hat.com>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 Dietmar Eggemann <dietmar.eggemann@....com>, Ben Segall
 <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
 Valentin Schneider <vschneid@...hat.com>, Shuah Khan <shuah@...nel.org>,
 linux-kernel@...r.kernel.org, linux-fsdevel@...r.kernel.org,
 linux-mm@...ck.org, linux-trace-kernel@...r.kernel.org,
 linux-kselftest@...r.kernel.org
Subject: Re: [PATCH v4 2/5] mm/selftests: add max_vma_count tests

On 28.10.25 22:24, Kalesh Singh wrote:
> Add a new selftest to verify that the max VMA count limit is correctly
> enforced.
> 
> This test suite checks that various VMA operations (mmap, mprotect,
> munmap, mremap) succeed or fail as expected when the number of VMAs is
> close to the sysctl_max_map_count limit.
> 
> The test works by first creating a large number of VMAs to bring the
> process close to the limit, and then performing various operations that
> may or may not create new VMAs. The test then verifies that the
> operations that would exceed the limit fail, and that the operations
> that do not exceed the limit succeed.
> 
> NOTE: munmap is special as it's allowed to temporarily exceed the limit
> by one for splits as this will decrease back to the limit once the unmap
> succeeds.
> 
> Cc: Andrew Morton <akpm@...ux-foundation.org>
> Cc: David Hildenbrand <david@...hat.com>
> Cc: "Liam R. Howlett" <Liam.Howlett@...cle.com>
> Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>
> Cc: Mike Rapoport <rppt@...nel.org>
> Cc: Minchan Kim <minchan@...nel.org>
> Cc: Pedro Falcato <pfalcato@...e.de>
> Signed-off-by: Kalesh Singh <kaleshsingh@...gle.com>
> ---

[...]

No capacity to review the tests in detail :(

> +
> diff --git a/tools/testing/selftests/mm/run_vmtests.sh b/tools/testing/selftests/mm/run_vmtests.sh
> index d9173f2312b7..a85db61e6a92 100755
> --- a/tools/testing/selftests/mm/run_vmtests.sh
> +++ b/tools/testing/selftests/mm/run_vmtests.sh
> @@ -49,6 +49,8 @@ separated by spaces:
>   	test madvise(2) MADV_GUARD_INSTALL and MADV_GUARD_REMOVE options
>   - madv_populate
>   	test memadvise(2) MADV_POPULATE_{READ,WRITE} options
> +- max_vma_count
> +	tests for max vma_count
>   - memfd_secret
>   	test memfd_secret(2)
>   - process_mrelease
> @@ -426,6 +428,9 @@ fi # VADDR64
>   # vmalloc stability smoke test
>   CATEGORY="vmalloc" run_test bash ./test_vmalloc.sh smoke
>   
> +# test operations against max vma count limit
> +CATEGORY="max_vma_count" run_test ./max_vma_count_tests

I'd just call it CATEGORY="vma" or "vma_handling".

Which makes me wodnering whether "vma_merge" falls into the same category.

Smalls like mremap test is similar.

Point is that "CATEGORY" stops being really useful if we end up having a 
separate category for each test, right? :)

-- 
Cheers

David