From owner-freebsd-current Mon Jan 18 12:59:29 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA09988 for freebsd-current-outgoing; Mon, 18 Jan 1999 12:59:29 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA09981 for ; Mon, 18 Jan 1999 12:59:27 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id MAA00156; Mon, 18 Jan 1999 12:57:33 -0800 (PST) Received: from current1.whistle.com(207.76.205.22) via SMTP by alpo.whistle.com, id smtpdcWe132; Mon Jan 18 20:57:22 1999 Date: Mon, 18 Jan 1999 12:57:02 -0800 (PST) From: Julian Elischer To: Matthew Dillon cc: Brian Feldman , Mike Smith , current@FreeBSD.ORG Subject: Re: kernel malloc and M_CANWAIT In-Reply-To: <199901182040.MAA78403@apollo.backplane.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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