From owner-cvs-all Tue Jan 30 3:45:20 2001 Delivered-To: cvs-all@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id E56D837B6AE; Tue, 30 Jan 2001 03:44:59 -0800 (PST) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id WAA10163; Tue, 30 Jan 2001 22:44:35 +1100 Date: Tue, 30 Jan 2001 22:44:21 +1100 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Peter Wemm Cc: Alfred Perlstein , Bosko Milekic , Boris Popov , 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: <200101300240.f0U2ei459361@mobile.wemm.org> 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, Peter Wemm wrote: > Yes, in an ideal world, we should always have a recovery path. But we do > not in all cases. Yes, this should be discouraged. M_WAITOK | M_PANIC > will generally die only if kmem_map fills up. The system is truely in > trouble at that point anyway, and if we didn't kill it gracedully then one > of the many other places that dont check returns from malloc(foo, M_WAITOK) > will get a page fault moments later. Erm, malloc(..., M_WAITOK) will wait forever if kmem_map fills up. It never returns NULL. Combining M_PANIC with M_WAITOK is bogus. The code that panics is never reached in the M_NOWAIT case. Example of this bogus combination: sys/net/if_loop.c. Code that checks for it returning NULL is bogus and should be examined for bugs (perhaps it meant to use M_NOWAIT). Example of such code: sys/i386/isa/intr_machdep.c. > IMHO, it is *far* better to get a panic than a page fault. Getting neither > is better still, but we do not live in that ideal world yet. I'm not sure about this. (1) Page faults cause panics. The only problem is that the fault may occur in a different context where panics don't work right and/or it is hard to find the original context for debugging. (It is not hard to diagnose that panics were caused by null pointers). (2) A pagefault immediately after the malloc() would be almost equivalent to a panic in malloc(). Dereference the pointer immediately to get a panic immediately. It *is* better to get a panic or a page fault than to wait forever. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message