From owner-cvs-all Mon Jan 29 21:30: 3 2001 Delivered-To: cvs-all@freebsd.org Received: from relay.butya.kz (butya-gw.butya.kz [212.154.129.94]) by hub.freebsd.org (Postfix) with ESMTP id 16AB137B402; Mon, 29 Jan 2001 21:29:40 -0800 (PST) Received: by relay.butya.kz (Postfix, from userid 1000) id A091A28D2B; Tue, 30 Jan 2001 11:29:31 +0600 (ALMT) Received: from localhost (localhost [127.0.0.1]) by relay.butya.kz (Postfix) with ESMTP id 7DBE328D2A; Tue, 30 Jan 2001 11:29:31 +0600 (ALMT) Date: Tue, 30 Jan 2001 11:29:31 +0600 (ALMT) From: Boris Popov X-Sender: bp@lion.butya.kz To: Bosko Milekic Cc: 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: <000901c08a73$c9b37f70$1f90c918@jehovah> 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 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. 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. -- Boris Popov http://www.butya.kz/~bp/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message