On Mon, May 21, 2018 at 6:19 PM Theodore Y. Ts'o <tytso@xxxxxxx> wrote: > 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. To be clear, I'm not suggesting that we actually perform this preallocation. (Maybe in the distant future, with strict commit accounting, it'd be useful.) I'm just suggesting that we perform the accounting as if we did. But I think Matthew's convinced me that there's no vsize cap small enough to be safe and still large enough to be useful, so I'll retract the vsize cap idea. > 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.... That'd be good too, but I don't see how this guarantee would be easier to make. If you call mmap three times, those three allocations might end up merged into the same VMA, and if you called munmap on the middle allocation, you'd still have to split. Am I misunderstanding something?
