On Mon, 21 May 2018 17:00:47 -0700 Daniel Colascione <dancol@xxxxxxxxxx> wrote: > On Mon, May 21, 2018 at 4:32 PM Dave Hansen <dave.hansen@xxxxxxxxx> wrote: > > > On 05/21/2018 04:16 PM, Daniel Colascione wrote: > > > On Mon, May 21, 2018 at 4:02 PM Dave Hansen <dave.hansen@xxxxxxxxx> > 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
