On Thu May 21 12:39:00 EDT 2009, r...@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
