Date: Mon, 18 Jan 1999 20:28:21 -0500 (EST) From: Brian Feldman <green@unixhelp.org> To: Mike Smith <mike@smith.net.au> Cc: Bruce Evans <bde@zeta.org.au>, current@FreeBSD.ORG Subject: Re: kernel malloc and M_CANWAIT Message-ID: <Pine.BSF.4.05.9901182027140.5579-100000@janus.syracuse.net> In-Reply-To: <199901182233.OAA19242@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 18 Jan 1999, Mike Smith wrote: > > > 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. > > > > Callers that check for NULL are bogus. > > If it can truly never return NULL, that's true. But it would also be > true to say that callers that can't deal with a veto return and that > can't guarantee deadlock avoidance are also bogus. > > I got the impression that my understanding of M_WAITOK's behaviour > came from a discussion with you about it, but it looks like I was > mistaken. Everyone else's impression of malloc M_WAITOK's behavior has always been that it could never return NULL, at least without (say) trying to allocate all available kernel memory. > > -- > \\ Sometimes you're ahead, \\ Mike Smith > \\ sometimes you're behind. \\ mike@smith.net.au > \\ The race is long, and in the \\ msmith@freebsd.org > \\ end it's only with yourself. \\ msmith@cdrom.com > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman _ __ ___ ___ ___ green@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ ____ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ ____ _____ |___/___/___/ 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.4.05.9901182027140.5579-100000>