Date: Fri, 26 May 2006 13:15:02 +0200 From: Fabian Keil <freebsd-listen@fabiankeil.de> To: Iasen Kostov <tbyte@otel.net> Cc: freebsd-stable@freebsd.org Subject: Re: kmem leak in tmpmfs? Message-ID: <20060526131502.2a2f984d@localhost> In-Reply-To: <1148639184.78660.32.camel@DraGoN.OTEL.net> References: <wpy7wq6qlh.fsf@heho.labo> <20060525205414.GC30137@xor.obsecurity.org> <1148639184.78660.32.camel@DraGoN.OTEL.net>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --]
Iasen Kostov <tbyte@otel.net> 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.
Fabian
--
http://www.fabiankeil.de/
[-- Attachment #2 --]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (FreeBSD)
iD8DBQFEduM7jV8GA4rMKUQRAqG2AKDBdtkz0Vjq2o/6U6vip51GMhE2XwCfdg0z
9clYMbd0gbW9TTPza0X7psk=
=AYvJ
-----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060526131502.2a2f984d>