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>