STOP DOING VMA_MERGE()
VIRTUAL MEMORY AREAS WERE SUPPOSED TO REMAIN SEPARATE
YEARS OF MERGING yet NO REAL-WORLD USE FOUND trying to limit process vma count to less than your FINGERS
Wanted to go lower anyway for a laugh? We had a sysctl for that: It was called "vm.max_map_count"
"Can we merge the PREDECESSOR?" "Can we merge the SUCCESSOR?" "Can we merge BOTH the PREDECESSOR and the SUCCESSOR?" - Statements dreamed up by the utterly Deranged.
LOOK at what the mremap(), brk() and mprotect() has been demanding your Support for all this time, with all the 8 different cases of merging we built for them.
(This is REAL Code, done by REAL Kernel developers).
if (addr == prev->vm_end && mpol_equal(vma_policy(prev), policy) ?????
&& can_vma_merge_after(prev, vm_flags, anon_vma, file,
pgoff, vm_userfaultfd_ctx, anon_name)) { ???????
merge_prev = true; ?????????????????
"Hello, I would like PPPPCCCCNNNN to become PPPPNNNNNNNN please"
They have played us for absolute fools
https://lore.kernel.org/linux-mm/20240401192623.18575-2-vbabka@suse.cz/T/#u