From owner-cvs-all Mon Jan 29 18:41:27 2001 Delivered-To: cvs-all@freebsd.org Received: from mobile.wemm.org (c1315225-a.plstn1.sfba.home.com [65.0.135.147]) by hub.freebsd.org (Postfix) with ESMTP id 63A0C37B402; Mon, 29 Jan 2001 18:40:59 -0800 (PST) Received: from netplex.com.au (localhost [127.0.0.1]) by mobile.wemm.org (8.11.1/8.11.1) with ESMTP id f0U2ei459361; Mon, 29 Jan 2001 18:40:44 -0800 (PST) (envelope-from peter@netplex.com.au) Message-Id: <200101300240.f0U2ei459361@mobile.wemm.org> X-Mailer: exmh version 2.2 06/23/2000 with nmh-1.0.4 To: Alfred Perlstein Cc: Bosko Milekic , Boris Popov , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_malloc.c src/sys/sys malloc.h In-Reply-To: <20010129114347.A26076@fw.wintelcom.net> Date: Mon, 29 Jan 2001 18:40:44 -0800 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein wrote: > * Bosko Milekic [010129 11:37] wrote: > > > > Boris Popov wrote: > > > > > bp 2001/01/29 04:48:41 PST > > > > > > Modified files: > > > sys/kern kern_malloc.c > > > sys/sys malloc.h > > > Log: > > > Add M_PANIC flag to the list of available flags passed to > > malloc(). > > > With this flag set malloc() will panic if memory allocation > > failed. > > > This usable only in critical places where failed allocation is > > fatal. > > > > > > Reviewed by: peter > > > > > > Revision Changes Path > > > 1.81 +7 -3 src/sys/kern/kern_malloc.c > > > 1.52 +2 -1 src/sys/sys/malloc.h > > > > Why is this change necessary? Rather, how is this change correct? I'd > > rather not introduce this sort of thing into the actual interface, > > unless it's realistically necessary, as I can see how this may > > encourage some people writing drivers (or an equivalent) to decide > > that they ought to panic the machine if they can't allocate. I'd > > rather see this dealt with, where absolutely necessary, by calling > > malloc() with M_NOWAIT and checking the return value and then calling > > panic explicitly if it is NULL. > > I agree with Bosko on this one, it's pretty wrong, we had many > problems in 2.2.x and early 3.x systems because of just giving up > on resource shortages (mbufs), we should be able to eventually fix > any places where a NULL return from malloc can't be handled, not > encourage giving up. Yes, in an ideal world, we should always have a recovery path. But we do not in all cases. Yes, this should be discouraged. M_WAITOK | M_PANIC will generally die only if kmem_map fills up. The system is truely in trouble at that point anyway, and if we didn't kill it gracedully then one of the many other places that dont check returns from malloc(foo, M_WAITOK) will get a page fault moments later. IMHO, it is *far* better to get a panic than a page fault. Getting neither is better still, but we do not live in that ideal world yet. Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message