From owner-cvs-all  Mon Jan 29 11:44:16 2001
Delivered-To: cvs-all@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id 8648937B404; Mon, 29 Jan 2001 11:43:49 -0800 (PST)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id f0TJhlm26373;
	Mon, 29 Jan 2001 11:43:47 -0800 (PST)
Date: Mon, 29 Jan 2001 11:43:47 -0800
From: Alfred Perlstein <bright@wintelcom.net>
To: Bosko Milekic <bmilekic@technokratis.com>
Cc: Boris Popov <bp@FreeBSD.org>, cvs-committers@FreeBSD.org,
	cvs-all@FreeBSD.org
Subject: Re: cvs commit: src/sys/kern kern_malloc.c src/sys/sys malloc.h
Message-ID: <20010129114347.A26076@fw.wintelcom.net>
References: <200101291248.f0TCmg157616@freefall.freebsd.org> <00ff01c08a2a$f4d98710$1f90c918@jehovah>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <00ff01c08a2a$f4d98710$1f90c918@jehovah>; from bmilekic@technokratis.com on Mon, Jan 29, 2001 at 02:37:46PM -0500
Sender: owner-cvs-all@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

* Bosko Milekic <bmilekic@technokratis.com> [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.

I'm also not that thrilled to see malloc getting (yes only slightly)
heavier as more and more features are added, this is an exceptional
case because it only affects failure, but we do need to be careful.

-- 
-Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org]
"I have the heart of a child; I keep it in a jar on my desk."


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message