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-current" 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>