From owner-freebsd-current Mon Jan 18 12:41:07 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA06768 for freebsd-current-outgoing; Mon, 18 Jan 1999 12:41:07 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA06758 for ; Mon, 18 Jan 1999 12:41:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.1/8.9.1) id MAA78403; Mon, 18 Jan 1999 12:40:59 -0800 (PST) (envelope-from dillon) Date: Mon, 18 Jan 1999 12:40:59 -0800 (PST) From: Matthew Dillon Message-Id: <199901182040.MAA78403@apollo.backplane.com> To: Brian Feldman Cc: Mike Smith , Julian Elischer , current@FreeBSD.ORG Subject: Re: kernel malloc and M_CANWAIT Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> > 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. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message