Date: Tue, 30 Jan 2001 23:02:31 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Boris Popov <bp@FreeBSD.org> Cc: Bosko Milekic <bmilekic@technokratis.com>, 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: <Pine.BSF.4.21.0101302252370.1284-100000@besplex.bde.org> In-Reply-To: <Pine.BSF.4.21.0101301113150.47663-100000@lion.butya.kz>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0101302252370.1284-100000>