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 <[email protected]>
Cc: David Hildenbrand <[email protected]>
Cc: "Liam R. Howlett" <[email protected]>
Cc: Lorenzo Stoakes <[email protected]>
Cc: Mike Rapoport <[email protected]>
Cc: Minchan Kim <[email protected]>
Cc: Pedro Falcato <[email protected]>
Signed-off-by: Kalesh Singh <[email protected]>
---
[...]
/*
@@ -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 :)
--
Cheers
David / dhildenb
