On Mon, May 21, 2018 at 05:38:06PM -0700, Daniel Colascione wrote: > > One approach to dealing with this badness, the one I proposed earlier, is > to prevent that giant mmap from appearing in the first place (because we'd > cap vsize). If that giant mmap never appears, you can't generate a huge VMA > tree by splitting it. > > Maybe that's not a good approach. Maybe processes really need mappings that > big. If they do, then maybe the right approach is to just make 8 billion > VMAs not "DoS the system". What actually goes wrong if we just let the VMA > tree grow that large? So what if VMA lookup ends up taking a while --- the > process with the pathological allocation pattern is paying the cost, right? > Fine. Let's pick a more reasonable size --- say, 1GB. That's still 2**18 4k pages. Someone who munmap's every other 4k page is going to create 2**17 VMA's. That's a lot of VMA's. So now the question is do we pre-preserve enough VMA's for this worst case scenario, for all processes in the system? Or do we fail or otherwise kill the process who is clearly attempting a DOS attack on the system? If your goal is that munmap must ***never*** fail, then effectively you have to preserve enough resources for 50% of all 4k pages in all of the virtual address spaces in use by all of the processes in the system. That's a horrible waste of resources, just to guarantee that munmap(2) must never fail. Personally, I think it's not worth it. Why is it so important to you that munmap(2) must not fail? Is it not enough to say that if you mmap(2) a region, if you munmap(2) that exact same size region as you mmap(2)'ed, it must not fail? That's a much easier guarantee to make.... - Ted
