Re: Why do we let munmap fail?

[Nicholas Piggin <npiggin@gmail.com>]

On Mon, 21 May 2018 17:00:47 -0700
Daniel Colascione <dancol@google.com> wrote:

> On Mon, May 21, 2018 at 4:32 PM Dave Hansen <dave.hansen@intel.com> wrote:
> 
> > On 05/21/2018 04:16 PM, Daniel Colascione wrote:  
> > > On Mon, May 21, 2018 at 4:02 PM Dave Hansen <dave.hansen@intel.com>  
> wrote:
> > >  
> > >> On 05/21/2018 03:54 PM, Daniel Colascione wrote:  
> > >>>> There are also certainly denial-of-service concerns if you allow
> > >>>> arbitrary numbers of VMAs.  The rbtree, for instance, is O(log(n)),  
> but
> > >>>> I 'd be willing to be there are plenty of things that fall over if  
> you
> > >>>> let the ~65k limit get 10x or 100x larger.  
> > >>> Sure. I'm receptive to the idea of having *some* VMA limit. I just  
> think
> > >>> it's unacceptable let deallocation routines fail.  
> > >> If you have a resource limit and deallocation consumes resources, you
> > >> *eventually* have to fail a deallocation.  Right?  
> > > That's why robust software sets aside at allocation time whatever  
> resources
> > > are needed to make forward progress at deallocation time.  
> 
> > I think there's still a potential dead-end here.  "Deallocation" does
> > not always free resources.  
> 
> Sure, but the general principle applies: reserve resources when you *can*
> fail so that you don't fail where you can't fail.

munmap != deallocation, it's a request to change the address mapping.
A more complex mapping uses more resources. mmap can free resources
if it transforms your mapping to a simpler one.

Thanks,
Nick