> On 29 Mar 2018, at 00:07, Luck, Tony <tony.l...@intel.com> wrote: > >> The default limit of only 65536 VMAs will also quickly come into play >> if consecutive anon mmaps don't get merged. Of course this can be >> raised, but it has significant resource and performance (fork) costs. > > Could the random mmap address chooser look for how many existing > VMAs have space before/after and the right attributes to merge with the > new one you want to create? If this is above some threshold (100?) then > pick one of them randomly and allocate the new address so that it will > merge from below/above with an existing one. > > That should still give you a very high degree of randomness, but prevent > out of control numbers of VMAs from being created.
I think this wouldn’t work. For example these 100 allocation may happened on process initialization. But when attacker come to the server all his allocations would be made on the predictable offsets from each other. So in result we did nothing just decrease performance of first 100 allocations. I think I can make ioctl to turn off this randomization per process and it could be used if needed. For example if application going to allocate big chunk or make big memory pressure, etc. Best regards, Ilya _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
