From owner-freebsd-stable@FreeBSD.ORG Mon Mar 5 20:00:23 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 EACB016A403 for ; Mon, 5 Mar 2007 20:00:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay02.kiev.sovam.com (relay02.kiev.sovam.com [62.64.120.197]) by mx1.freebsd.org (Postfix) with ESMTP id 7D8B513C4AC for ; Mon, 5 Mar 2007 20:00:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay02.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1HOItK-000OWZ-Bj for stable@freebsd.org; Mon, 05 Mar 2007 21:30:46 +0200 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l25JUMan083803 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Mar 2007 21:30:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8) with ESMTP id l25JUM3C013567; Mon, 5 Mar 2007 21:30:22 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.13.8/8.13.8/Submit) id l25JUM8J013566; Mon, 5 Mar 2007 21:30:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 5 Mar 2007 21:30:22 +0200 From: Kostik Belousov To: Yar Tikhiy Message-ID: <20070305193022.GM10453@deviant.kiev.zoral.com.ua> 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> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="cy9Nn4fUvYST66Pl" Content-Disposition: inline In-Reply-To: <20070305191714.GF57253@comp.chem.msu.su> User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on fw.zoral.com.ua X-Scanner-Signature: 96b5a640d20a32298b7e0b1f479135d9 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 837 [Mar 05 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release 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:00:24 -0000 --cy9Nn4fUvYST66Pl Content-Type: text/plain; charset=koi8-r Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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: > > =3D > How will it break them? =9Aswap backing only touches swap if ther= e is > > =3D > memory pressure, i.e. precisely the situation in which malloc bac= king > > =3D > will panic. > > =3D=20 > > =3D I forgot that in BSD swap wouldn't be allocated in advance to its > > =3D consumers. =9AThen removing the -M flag and making swap backing the > > =3D default is a very sound choice. =9AThank you for correcting me. > >=20 > > Yar, would you change the man-page's advice and the default, then? >=20 > Yes, I'll be glad to if no objections arise until I finish updating > my CURRENT machine, i.e., tomorrow. :-) >=20 > > Someone still needs to look into the panic... Who would that be? >=20 > Obviously, Mr(s). Someone. :-) >=20 > 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: >=20 > - 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. >=20 > 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. --cy9Nn4fUvYST66Pl Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (FreeBSD) iD8DBQFF7G/NC3+MBN1Mb4gRAuFeAJ4m4uHlhOSDkMNTNnVPKD2M+AOZwQCfZyZU tHPAxGJ5DdwTafK6NLCKTLo= =IWVy -----END PGP SIGNATURE----- --cy9Nn4fUvYST66Pl--