linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH v4 0/5] mm: Refactor and improve VMA count limit code
@ 2025-10-28 21:24 Kalesh Singh
  2025-10-28 21:24 ` [PATCH v4 1/5] mm: Document lenient map_count checks Kalesh Singh
                   ` (4 more replies)
  0 siblings, 5 replies; 9+ messages in thread
From: Kalesh Singh @ 2025-10-28 21:24 UTC (permalink / raw)
  To: akpm, minchan, lorenzo.stoakes, david, Liam.Howlett, rppt, pfalcato
  Cc: rostedt, hughd, kernel-team, android-mm, Kalesh Singh,
	Alexander Viro, Christian Brauner, Jan Kara, Kees Cook,
	Vlastimil Babka, Suren Baghdasaryan, Michal Hocko, Jann Horn,
	Masami Hiramatsu, Mathieu Desnoyers, Ingo Molnar, Peter Zijlstra,
	Juri Lelli, Vincent Guittot, Dietmar Eggemann, Ben Segall,
	Mel Gorman, Valentin Schneider, Shuah Khan, linux-kernel,
	linux-fsdevel, linux-mm, linux-trace-kernel, linux-kselftest

Hi all,

This series refactors the VMA count limit code to improve clarity,
test coverage, and observability.

The VMA count limit, controlled by sysctl_max_map_count, is a safeguard
that prevents a single process from consuming excessive kernel memory
by creating too many memory mappings.

A major change since v3 is the first patch in the series which instead of 
attempting to fix overshooting the limit now documents that this is the
intended behavior. As Hugh pointed out, the lenient check (>) in do_mmap()
and do_brk_flags() is intentional to allow for potential VMA merges or
expansions when the process is at the sysctl_max_map_count limit. 
The consensus is that this historical behavior is correct but non-obvious.

This series now focuses on making that behavior clear and the surrounding
code more robust. Based on feedback from Lorenzo and David, this series
retains the helper function and the rename of map_count.

The refined v4 series is now structured as follows:

1.  Documents the lenient VMA count checks with comments to clarify
    their purpose.

2.  Adds a comprehensive selftest to codify the expected behavior at the
    limit, including the lenient mmap case.

3.  Introduces max_vma_count() to abstract the max map count sysctl,
    making the sysctl static and converting all callers to use the new
    helper.

4.  Renames mm_struct->map_count to the more explicit vma_count for
    better code clarity.

5.  Adds a tracepoint for observability when a process fails to
    allocate a VMA due to the count limit.

Tested on x86_64 and arm64:

 1. Build test:
      allyesconfig for rename

 2. Selftests:
      cd tools/testing/selftests/mm && \
          make && \
          ./run_vmtests.sh -t max_vma_count

 3. vma tests:
      cd tools/testing/vma && \
          make && \
          ./vma

Link to v3:
https://lore.kernel.org/r/20251013235259.589015-1-kaleshsingh@google.com/

Thanks to everyone for the valuable discussion on previous revisions.

-- Kalesh

Kalesh Singh (5):
  mm: Document lenient map_count checks
  mm/selftests: add max_vma_count tests
  mm: Introduce max_vma_count() to abstract the max map count sysctl
  mm: rename mm_struct::map_count to vma_count
  mm/tracing: introduce trace_mm_insufficient_vma_slots event

 MAINTAINERS                                   |   2 +
 fs/binfmt_elf.c                               |   2 +-
 fs/coredump.c                                 |   2 +-
 include/linux/mm.h                            |   2 -
 include/linux/mm_types.h                      |   2 +-
 include/trace/events/vma.h                    |  32 +
 kernel/fork.c                                 |   2 +-
 mm/debug.c                                    |   2 +-
 mm/internal.h                                 |   3 +
 mm/mmap.c                                     |  25 +-
 mm/mremap.c                                   |  13 +-
 mm/nommu.c                                    |   8 +-
 mm/util.c                                     |   1 -
 mm/vma.c                                      |  42 +-
 mm/vma_internal.h                             |   2 +
 tools/testing/selftests/mm/.gitignore         |   1 +
 tools/testing/selftests/mm/Makefile           |   1 +
 .../selftests/mm/max_vma_count_tests.c        | 716 ++++++++++++++++++
 tools/testing/selftests/mm/run_vmtests.sh     |   5 +
 tools/testing/vma/vma.c                       |  32 +-
 tools/testing/vma/vma_internal.h              |  13 +-
 21 files changed, 856 insertions(+), 52 deletions(-)
 create mode 100644 include/trace/events/vma.h
 create mode 100644 tools/testing/selftests/mm/max_vma_count_tests.c


base-commit: b227c04932039bccc21a0a89cd6df50fa57e4716
-- 
2.51.1.851.g4ebd6896fd-goog



^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2025-11-03 23:58 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2025-10-28 21:24 [PATCH v4 0/5] mm: Refactor and improve VMA count limit code Kalesh Singh
2025-10-28 21:24 ` [PATCH v4 1/5] mm: Document lenient map_count checks Kalesh Singh
2025-11-03 17:08   ` David Hildenbrand (Red Hat)
2025-10-28 21:24 ` [PATCH v4 2/5] mm/selftests: add max_vma_count tests Kalesh Singh
2025-11-03 17:13   ` David Hildenbrand (Red Hat)
2025-11-03 23:58     ` Kalesh Singh
2025-10-28 21:24 ` [PATCH v4 3/5] mm: Introduce max_vma_count() to abstract the max map count sysctl Kalesh Singh
2025-10-28 21:24 ` [PATCH v4 4/5] mm: rename mm_struct::map_count to vma_count Kalesh Singh
2025-10-28 21:24 ` [PATCH v4 5/5] mm/tracing: introduce trace_mm_insufficient_vma_slots event Kalesh Singh

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox