Re: Why do we let munmap fail?

["Theodore Y. Ts'o" <tytso@mit.edu>]

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