Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 18 Jan 2003 13:22:45 +0100
From:      Thomas Moestl <tmoestl@gmx.net>
To:        phk@freebsd.org
Cc:        Kris Kennaway <kris@obsecurity.org>, current@freebsd.org, alpha@freebsd.org
Subject:   Re: panic: malloc(M_WAITOK) returned NULL
Message-ID:  <20030118122245.GA283@crow.dom2ip.de>
In-Reply-To: <18381.1042876839@critter.freebsd.dk>
References:  <20030118045316.GA25224@rot13.obsecurity.org> <18381.1042876839@critter.freebsd.dk>

next in thread | previous in thread | raw e-mail | index | archive | help
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 <tmoestl@gmx.net>	http://www.tu-bs.de/~y0015675/
              <tmm@FreeBSD.org>	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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030118122245.GA283>