On Thu, Oct 11, 2018 at 1:39 PM Jann Horn <jannh@xxxxxxxxxx> wrote: > > On Thu, Oct 11, 2018 at 5:20 PM Yu-cheng Yu <yu-cheng.yu@xxxxxxxxx> wrote: > > Create a guard area between VMAs to detect memory corruption. > [...] > > +config VM_AREA_GUARD > > + bool "VM area guard" > > + default n > > + help > > + Create a guard area between VM areas so that access beyond > > + limit can be detected. > > + > > endmenu > > Sorry to bring this up so late, but Daniel Micay pointed out to me > that, given that VMA guards will raise the number of VMAs by > inhibiting vma_merge(), people are more likely to run into > /proc/sys/vm/max_map_count (which limits the number of VMAs to ~65k by > default, and can't easily be raised without risking an overflow of > page->_mapcount on systems with over ~800GiB of RAM, see > https://lore.kernel.org/lkml/20180208021112.GB14918@xxxxxxxxxxxxxxxxxxxxxx/ > and replies) with this change. > > Playing with glibc's memory allocator, it looks like glibc will use > mmap() for 128KB allocations; so at 65530*128KB=8GB of memory usage in > 128KB chunks, an application could run out of VMAs. Ugh. Do we have a free VM flag so we could do VM_GUARD to force a guard page? (And to make sure that, when a new VMA is allocated, it won't be directly adjacent to a VM_GUARD VMA.)
