Re: [9fans] aux/acidleak pool pathology

[Russ Cox <rsc@swtch.com>]

On Thu, May 21, 2009 at 9:54 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> 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.

all allocators have fragmentation and reuse problems.
some are better than others, but they all do.
linear reallocs are always a bad idea; the worse
part is requiring the array to be contiguous in the
first place, but you can't qsort a linked list.

if upas/fs is allocating arbitrarily large buffers,
then its allocation behavior is broken too.

> 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.

if the kernel can be forced to allocate an arbitrarily
large chunk of data, that's the bug to fix, not the
allocator behavior.  it probably can, in its handling
of strings like user names and large paths passed
to open.  /dev/zero doesn't allocate at all.

russ