From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: From: erik quanstrom Date: Thu, 21 May 2009 12:54:00 -0400 To: 9fans@9fans.net In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit Subject: Re: [9fans] aux/acidleak pool pathology Topicbox-Message-UUID: fc05cb82-ead4-11e9-9d60-3106f5b1d025 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