From owner-cvs-all Tue Jan 30 4: 3:10 2001 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id 9450137B6B6; Tue, 30 Jan 2001 04:02:47 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id XAA11594; Tue, 30 Jan 2001 23:02:45 +1100 Date: Tue, 30 Jan 2001 23:02:31 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Boris Popov Cc: Bosko Milekic , 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: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 30 Jan 2001, Boris Popov wrote: > On Mon, 29 Jan 2001, Bosko Milekic wrote: > > > In this case, don't you agree that using malloc() with M_WAITOK > > would be more appropriate? In the broken state that it is, > > kmem_malloc() will panic if it can't find the address space in > > kmem_map _anyway_, as long as you're calling with M_WAITOK. Adding > > M_PANIC is redundant in this light. M_PANIC is good for handling all the code that uses M_NOWAIT. > Dunno, the line 189 in kern_malloc.c (rev 1.80) tells that the > return value can be NULL even with M_WAITOK. If this is not true then > this change is obviously wrong. This seems to result from confusion about M_WAITOK. There was a lot of confusion about this in 386BSD-0.0. I thought that it was understood now. It's behaviour of causing malloc() to wait and never return NULL is even documented in malloc.9 :-). Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message