From owner-freebsd-stable@FreeBSD.ORG Fri May 26 11:25:22 2006 Return-Path: X-Original-To: freebsd-stable@freebsd.org Delivered-To: freebsd-stable@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E5D5016A428 for ; Fri, 26 May 2006 11:25:22 +0000 (UTC) (envelope-from tbyte@otel.net) Received: from mail.otel.net (gw3.OTEL.net [212.36.8.151]) by mx1.FreeBSD.org (Postfix) with ESMTP id 0F94243D82 for ; Fri, 26 May 2006 11:24:59 +0000 (GMT) (envelope-from tbyte@otel.net) Received: from dragon.otel.net ([212.36.8.135]) by mail.otel.net with esmtp (Exim 4.60 (FreeBSD)) (envelope-from ) id 1FjaR8-0001HA-A8; Fri, 26 May 2006 14:24:58 +0300 From: Iasen Kostov To: Fabian Keil In-Reply-To: <20060526131502.2a2f984d@localhost> References: <20060525205414.GC30137@xor.obsecurity.org> <1148639184.78660.32.camel@DraGoN.OTEL.net> <20060526131502.2a2f984d@localhost> Content-Type: text/plain Date: Fri, 26 May 2006 14:24:57 +0300 Message-Id: <1148642697.78660.41.camel@DraGoN.OTEL.net> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: freebsd-stable@freebsd.org Subject: Re: kmem leak in tmpmfs? X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 May 2006 11:25:23 -0000 On Fri, 2006-05-26 at 13:15 +0200, Fabian Keil wrote: > Iasen Kostov wrote: > > > On Thu, 2006-05-25 at 16:54 -0400, Kris Kennaway wrote: > > > On Thu, May 25, 2006 at 06:01:30PM +0200, Arno J. Klaassen wrote: > > > > > I get a very easy to reproduce panic on 6.1-STABLE : > > > > > > > > /etc/periodic/weekly/310.locate panics with > > > > > > > > panic: kmem_malloc(4096): kmem_map too small: 335544320 total > > > > allocated > > > > > > It looks like you are using a malloc-backed md and you do not have > > > enough RAM to handle the size. Perhaps tmpmfs does not use swap > > > backing, as it is supposed to? > > > First of all if there is not enough kmem (not just plain ram > > I think) kernel should not allow disk creation in first place, second > > - I think (although there could be some ... reason for that) it's > > stupid way to say "I don't have more kmem" by panicing :). Better way > > will be just to fail disk operation of that FS with "Disk is full" or > > something like that. At home I tried to raise kmem like that: > > "vm.kmem_size_max="1073741824" (I got 2G of RAM) > > (setting vm.kmem_size directly panices kernel at boot if I remember > > correctly). > > > > but for my surprise kernel panices at exact same allocated md disk > > space with the same panic as the original poster's. Is it possible > > that I should rise KVA_PAGES too ? And I don't think its documented > > anywhere (of course I've tried googling and it's always possible that > > I've missed something :). All this was on FreeBSD 6.0. > > man mdconfig mentions the problem: > > malloc Storage for this type of memory disk is allocated with > malloc(9). This limits the size to the malloc bucket > limit in the kernel. If the -o reserve option is not > set, creating and filling a large malloc-backed memory > disk is a very easy way to panic a system. > > Use a swap backed disk and the problem will disappear. I ment KVA_PAGES (If it is the limit). But may be "malloc bucket limit" (which I don't realy understand what it means) has something to do with it ? But whatever is the cause I think it no good practice to leave such easy ways to panic the kernel unsecured/pached/fixed. And I wander why even when I set kmem_size_max to 1G kernel still panices around 350MB allocated md space ? I mean what is the real issue there ? Regards.