Date: Tue, 30 Jan 2001 22:44:21 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Peter Wemm <peter@netplex.com.au> Cc: Alfred Perlstein <bright@wintelcom.net>, Bosko Milekic <bmilekic@technokratis.com>, Boris Popov <bp@FreeBSD.org>, 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.0101302222100.1134-100000@besplex.bde.org> In-Reply-To: <200101300240.f0U2ei459361@mobile.wemm.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0101302222100.1134-100000>