From owner-cvs-all Mon Jan 29 20:17:48 2001 Delivered-To: cvs-all@freebsd.org Received: from VL-MS-MR001.sc1.videotron.ca (relais.videotron.ca [24.201.245.36]) by hub.freebsd.org (Postfix) with ESMTP id 5957537B402; Mon, 29 Jan 2001 20:17:23 -0800 (PST) Received: from jehovah ([24.201.144.31]) by VL-MS-MR001.sc1.videotron.ca (Netscape Messaging Server 4.15) with SMTP id G7YJWW00.AKC; Mon, 29 Jan 2001 23:17:20 -0500 Message-ID: <000901c08a73$c9b37f70$1f90c918@jehovah> From: "Bosko Milekic" To: "Boris Popov" Cc: , References: Subject: Re: cvs commit: src/sys/kern kern_malloc.c src/sys/sys malloc.h Date: Mon, 29 Jan 2001 23:19:07 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Boris Popov wrote: [...] > As commit message states, this flag should be used only as a last > resort and only in really critical places where it is impossible to > continue if memory allocation failed. In my case it saved a lots of 'if > (blah == NULL) panic()' in the specific subsystem (in the terms of saved > bytes in the code segment, not extra lines in the source file). This is > completely safe in this case because kernel will be completely broken if > one of malloc()s failed. 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. > -- > Boris Popov > http://www.butya.kz/~bp/ Regards, Bosko. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message