From owner-freebsd-stable@FreeBSD.ORG Sun Mar 4 08:27:58 2007 Return-Path: X-Original-To: stable@freebsd.org Delivered-To: freebsd-stable@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 19F7916A400 for ; Sun, 4 Mar 2007 08:27:58 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (comp.chem.msu.su [158.250.32.97]) by mx1.freebsd.org (Postfix) with ESMTP id 58FCE13C474 for ; Sun, 4 Mar 2007 08:27:56 +0000 (UTC) (envelope-from yar@comp.chem.msu.su) Received: from comp.chem.msu.su (localhost [127.0.0.1]) by comp.chem.msu.su (8.13.4/8.13.4) with ESMTP id l247xlL5047809; Sun, 4 Mar 2007 10:59:47 +0300 (MSK) (envelope-from yar@comp.chem.msu.su) Received: (from yar@localhost) by comp.chem.msu.su (8.13.4/8.13.4/Submit) id l247xkcg047808; Sun, 4 Mar 2007 10:59:46 +0300 (MSK) (envelope-from yar) Date: Sun, 4 Mar 2007 10:59:46 +0300 From: Yar Tikhiy To: Mikhail Teterin Message-ID: <20070304075946.GH40430@comp.chem.msu.su> References: <20070227205351.GA72597@ravenloft.kiev.ua> <200702271603.30481@aldan> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702271603.30481@aldan> User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org, Alex Kozlov Subject: Re: panic: kmem_malloc(16384): kmem_map too small: md-mounted /tmp filled up 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: Sun, 04 Mar 2007 08:27:58 -0000 On Tue, Feb 27, 2007 at 04:03:30PM -0500, Mikhail Teterin wrote: > On Tuesday 27 February 2007 15:53, Alex Kozlov wrote: > = > Yes, I switched to swap-backed md already. But the malloc-based variety is > = > currently the _default_ (see /etc/defaults/rc.conf)... > = Bad default. > > Filing a PR. Keep in mind that changing the default can break existing setups. Such setups are likely to be broken anyway, but... E.g., if we drop the -M flag, it will break systems with tons of RAM but little swap using tmpmfs. OTOH, if we add '-o reserve', that will break systems with a too large but mostly unused tmpmfs. A sort of a loud announcement will be needed. By the way, I seem to be the one responsible for the paragraph in rc.conf(5) advocating -M "for maximum performance and system stability at low memory conditions". When I wrote it, I thought as follows: were the system low on memory, additional swap activity due to mfs would just make the system start thrashing sooner, while malloc'd mfs would just report ENOSPC. I was unaware of the panic back then. Perhaps it was a misconception, either. I haven't heard of any real pitfalls in swap-backed mfs, and getting ENOSPC on /tmp early is no good. > = > Creation of a 2Gb malloc-based md should've failed on a machine with > = > 768Mb of RAM, shouldn't it have? > = Only if you set '-o reserve'. Memory for malloc-based md was allocated > = dynamically. > > But malloc can only allocate from RAM, right? So the amount of RAM is the hard > limit, which a malloc-based md can not exceed even in theory. This means, > md-creation should've failed... > > In fact, the limit should, of course, be even lower -- and mdmfs should be > smart enough to substract the sizes of other kernel memory chunks from the > maximum. > > Since even that would still not be a guarantee against running out, the system > should be able to recover gracefully instead of panicing. Do you agree? FWIW, some discussion of the panic is in the audit trail of kern/87255. Irrespective of tmpmfs defaults, this is a way to panic the system with stock tools and without doing something totally stupid like writing junk to /dev/mem. -- Yar