From owner-freebsd-stable@FreeBSD.ORG Mon Mar 5 20:13:38 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 2CEB016A405 for ; Mon, 5 Mar 2007 20:13:38 +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 6877F13C48D for ; Mon, 5 Mar 2007 20:13:37 +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 l25KDYOi072712; Mon, 5 Mar 2007 23:13:34 +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 l25KDXo7072711; Mon, 5 Mar 2007 23:13:33 +0300 (MSK) (envelope-from yar) Date: Mon, 5 Mar 2007 23:13:32 +0300 From: Yar Tikhiy To: Kostik Belousov Message-ID: <20070305201332.GH57253@comp.chem.msu.su> References: <20070227205351.GA72597@ravenloft.kiev.ua> <20070305035945.GA71660@xor.obsecurity.org> <20070305132350.GB57253@comp.chem.msu.su> <200703051314.29902@aldan> <20070305191714.GF57253@comp.chem.msu.su> <20070305193022.GM10453@deviant.kiev.zoral.com.ua> Mime-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20070305193022.GM10453@deviant.kiev.zoral.com.ua> User-Agent: Mutt/1.5.9i Cc: stable@freebsd.org 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: Mon, 05 Mar 2007 20:13:38 -0000 On Mon, Mar 05, 2007 at 09:30:22PM +0200, Kostik Belousov wrote: > On Mon, Mar 05, 2007 at 10:17:14PM +0300, Yar Tikhiy wrote: > > On Mon, Mar 05, 2007 at 01:14:29PM -0500, Mikhail Teterin wrote: > > > On Monday 05 March 2007 08:23, Yar Tikhiy wrote: > > > = > How will it break them? šswap backing only touches swap if there is > > > = > memory pressure, i.e. precisely the situation in which malloc backing > > > = > will panic. > > > = > > > = I forgot that in BSD swap wouldn't be allocated in advance to its > > > = consumers. šThen removing the -M flag and making swap backing the > > > = default is a very sound choice. šThank you for correcting me. > > > > > > Yar, would you change the man-page's advice and the default, then? > > > > Yes, I'll be glad to if no objections arise until I finish updating > > my CURRENT machine, i.e., tomorrow. :-) > > > > > Someone still needs to look into the panic... Who would that be? > > > > Obviously, Mr(s). Someone. :-) > > > > The md case exposes a quite tangled nature of the problem. Funnily > > enough, kernel malloc() cannot just fail in the case because it > > must not fail if called with M_WAITOK. This means that the system > > has quite a rough choice: > > > > - put the requesting thread to sleep forever; > > - grow kmem_map, eventually sacrifice all RAM to the greedy thread > > and die sooner or later; > > - panic immediately. > > > > If all malloc() callers in the kernel were ready to deal with > > allocation failure, the system could just tell the greedy thread > > to buzz off. But too many kernel parts depend on malloc(M_WAITOK) > > never failing. Perhaps it's the root of the problem. > > Mark callers that are ready for M_WAITOK failure with some additional > flag, like M_FAILOK (feel free to propose meaningful name there). > At least malloc()-based md could then use it. The problem isn't that we don't have such a flag yet. It's that some parts of the kernel would rather we didn't have it. :-) Of course, introducing the flag or changing semantics of malloc() in a similar way is a necessary start. -- Yar