From owner-freebsd-alpha Sat Jan 18 4:21: 4 2003 Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8484B37B406 for ; Sat, 18 Jan 2003 04:21:02 -0800 (PST) Received: from mail.gmx.net (mail.gmx.net [213.165.65.60]) by mx1.FreeBSD.org (Postfix) with SMTP id 3208E43F5F for ; Sat, 18 Jan 2003 04:21:00 -0800 (PST) (envelope-from tmoestl@gmx.net) Received: (qmail 30907 invoked by uid 0); 18 Jan 2003 12:20:58 -0000 Received: from p508e6b6b.dip.t-dialin.net (HELO galatea.local) (80.142.107.107) by mail.gmx.net (mp005-rz3) with SMTP; 18 Jan 2003 12:20:58 -0000 Received: from localhost ([127.0.0.1] helo=galatea.local) by galatea.local with esmtp (Exim 4.12 #1) id 18Zrzu-0000JV-00; Sat, 18 Jan 2003 13:22:50 +0100 Received: (from tmm@localhost) by galatea.local (8.12.6/8.12.6/Submit) id h0ICMjqk001208; Sat, 18 Jan 2003 13:22:45 +0100 (CET) Date: Sat, 18 Jan 2003 13:22:45 +0100 From: Thomas Moestl To: phk@freebsd.org Cc: Kris Kennaway , current@freebsd.org, alpha@freebsd.org Subject: Re: panic: malloc(M_WAITOK) returned NULL Message-ID: <20030118122245.GA283@crow.dom2ip.de> Mail-Followup-To: phk@freebsd.org, Kris Kennaway , current@freebsd.org, alpha@freebsd.org References: <20030118045316.GA25224@rot13.obsecurity.org> <18381.1042876839@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18381.1042876839@critter.freebsd.dk> User-Agent: Mutt/1.4i Sender: owner-freebsd-alpha@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org On Sat, 2003/01/18 at 09:00:39 +0100, phk@freebsd.org wrote: > In message <20030118045316.GA25224@rot13.obsecurity.org>, Kris Kennaway writes: > > >I just got the following on axp1: > > > >panic: malloc(M_WAITOK) returned NULL > >db_print_backtrace() at db_print_backtrace+0x18 > >panic() at panic+0x104 > >malloc() at malloc+0x1a8 > >initiate_write_inodeblock_ufs1() at initiate_write_inodeblock_ufs1+0xc4 > >softdep_disk_io_initiation() at softdep_disk_io_initiation+0xa4 > >spec_strategy() at spec_strategy+0x158 > >spec_vnoperate() at spec_vnoperate+0x2c > > This is a bug in the kernel memory allocator, since it should not be > able to return NULL when M_WAITOK is specified. The potential bugs > are more likely because M_WAITOK is defined as zero. I found two instances of bogus M_WAITOK tests a few days ago (but haven't received an answer from Jeff yet). The first occurance in the attached patch would cause malloc to fail if a zone was exhausted (without M_NOWAIT); the second one is mostly harmless. None of the two could have caused this panic. I would guess that it was caused by the alpha uma_small_alloc() implementation trying less hard to allocate a page than kmem_alloc() (i.e. it does not sleep at all). This problem does also affect the ia64 and sparc64 uma_small_alloc() versions it seems. - Thomas -- Thomas Moestl http://www.tu-bs.de/~y0015675/ http://people.FreeBSD.org/~tmm/ PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C Index: uma_core.c =================================================================== RCS file: /ncvs/src/sys/vm/uma_core.c,v retrieving revision 1.45 diff -u -r1.45 uma_core.c --- uma_core.c 1 Jan 2003 18:48:59 -0000 1.45 +++ uma_core.c 12 Jan 2003 23:15:49 -0000 @@ -1476,10 +1476,10 @@ zone->uz_pages >= zone->uz_maxpages) { zone->uz_flags |= UMA_ZFLAG_FULL; - if (flags & M_WAITOK) - msleep(zone, &zone->uz_lock, PVM, "zonelimit", 0); - else + if (flags & M_NOWAIT) break; + else + msleep(zone, &zone->uz_lock, PVM, "zonelimit", 0); continue; } zone->uz_recurse++; @@ -1499,7 +1499,7 @@ * could have while we were unlocked. Check again before we * fail. */ - if ((flags & M_WAITOK) == 0) + if (flags & M_NOWAIT) flags |= M_NOVM; } return (slab); @@ -1587,7 +1587,6 @@ } /* Don't block on the next fill */ flags |= M_NOWAIT; - flags &= ~M_WAITOK; } zone->uz_fills--; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-alpha" in the body of the message