Date: Mon, 29 Jan 2001 23:19:07 -0500 From: "Bosko Milekic" <bmilekic@technokratis.com> To: "Boris Popov" <bp@FreeBSD.org> Cc: <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: <000901c08a73$c9b37f70$1f90c918@jehovah> References: <Pine.BSF.4.21.0101300813090.46219-100000@lion.butya.kz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000901c08a73$c9b37f70$1f90c918>