On 15.09.25 18:36, Kalesh Singh wrote:
The checks against sysctl_max_map_count are open-coded in multiple places. While simple checks are manageable, the logic in places like mremap.c involves arithmetic with magic numbers that can be difficult to reason about. e.g. ... >= sysctl_max_map_count - 3
To improve readability and centralize the logic, introduce a new helper, vma_count_remaining(). This function returns the VMA count headroom available for a givine process.
s/givine/given/
s/process/mm/
The most common case of checking for a single new VMA can be done with the convenience helper has_vma_count_remaining():
if (!vma_count_remaining(mm))
And the complex checks in mremap.c become clearer by expressing the required capacity directly:
if (vma_count_remaining(mm) < 4)
While a capacity-based function could be misused (e.g., with an incorrect '<' vs '<=' comparison), the improved readability at the call sites makes such errors less likely than with the previous open-coded arithmetic.
As part of this change, sysctl_max_map_count is made static to mm/mmap.c to improve encapsulation.
Cc: Andrew Morton akpm@linux-foundation.org Cc: David Hildenbrand david@redhat.com Cc: "Liam R. Howlett" Liam.Howlett@oracle.com Cc: Lorenzo Stoakes lorenzo.stoakes@oracle.com Cc: Mike Rapoport rppt@kernel.org Cc: Minchan Kim minchan@kernel.org Cc: Pedro Falcato pfalcato@suse.de Signed-off-by: Kalesh Singh kaleshsingh@google.com
[...]
/* @@ -1504,6 +1504,25 @@ struct vm_area_struct *_install_special_mapping( int sysctl_legacy_va_layout; #endif +static int sysctl_max_map_count __read_mostly = DEFAULT_MAX_MAP_COUNT;
+/**
- vma_count_remaining - Determine available VMA slots
- @mm: The memory descriptor for the process.
- Check how many more VMAs can be created for the given @mm
- before hitting the sysctl_max_map_count limit.
- Return: The number of new VMAs the process can accommodate.
- */
+int vma_count_remaining(const struct mm_struct *mm) +{
- const int map_count = mm->map_count;
- const int max_count = sysctl_max_map_count;
If we worry about rare races (sysctl_max_map_count changing?) we should probably force a single read through READ_ONCE()?
Otherwise one might trick vma_count_remaining() into returning a negative number I assume.
- return (max_count > map_count) ? (max_count - map_count) : 0;
+}
Nothing else jumped at me.
Not sure what the buildbot complains about but I'm sure you'll figure it out :)