Date: Mon, 18 Jan 1999 12:57:02 -0800 (PST) From: Julian Elischer <julian@whistle.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Brian Feldman <green@unixhelp.org>, Mike Smith <mike@smith.net.au>, current@FreeBSD.ORG Subject: Re: kernel malloc and M_CANWAIT Message-ID: <Pine.BSF.3.95.990118125454.8525G-100000@current1.whistle.com> In-Reply-To: <199901182040.MAA78403@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Jan 1999, Matthew Dillon wrote: > :> > There was some talk about the fact that malloc(..M_CANWAIT) > :> > can now return with a failure. Is that true? > :> > :> Yes; it's necessary to do this to allow some chance of avoiding > :> deadlock. > : > :Ouch! Is everything in src-sys already checking the return value of an M_WAITOK? > : > : Brian Feldman _ __ ___ ___ ___ > > It looks like malloc() can return NULL if the kmem_malloc() fails. > > kmem_malloc() can only fail in the M_WAITOK case if the KVM map is full. > If the system is simply low on memory, kmem_malloc() will block. > > So malloc() will generally not return NULL even in low memory situations > unless the KVM map fills up, which isn't supposed to happen but can in > certain severe circumstances. Callers should therefore check for NULL. why not just put it in a loop and block on lbolt? (or call panic) the trouble is that this is a major change in semantics and will affect code flow all over the place. julian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" 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.3.95.990118125454.8525G-100000>