Re: [9fans] aux/acidleak pool pathology

[erik quanstrom <quanstro@quanstro.net>]

On Thu May 21 12:39:00 EDT 2009, rsc@swtch.com wrote:
> > obviously the Brdline loop in main is reallocating data and block
> > so they don't fit in their previous buckets and pool sbrk's more
> > memory.  it would seem that pool is missing the fact that
>
> It's probably a combination of data and block growing together
> along with the occasional estrdup that is causing the fragmentation.
> You should rewrite both of the reallocs to double the array when
> they outgrow the current one instead of growing by a fixed amount.
> The fixed amount is nice because it avoids the extra variable
> tracking the maximum size of the array, but it's a terrible algorithm.

in this simple case, that is an fine solution.  but i also see similar
behavior with upas/fs, especially when opening and closing multiple
mailboxes.  i was actually trying to debug a case where upas/fs has
sbrk'd 800mb but had not had an active set >43mb when i ran across
this behavior.

more importantly, since pool is used in the kernel, i would imagine
that a determined attacker could force the kernel to "run out" of
memory in a similar fashion.  perhaps by dd'ing large chunks and
small chunks from /dev/zero.  maybe there's a simple reason this can't
happen that i'm missing.  but i don't currently see it.

- erik