From owner-freebsd-ipfw@FreeBSD.ORG  Wed Aug 25 11:40:14 2004
Return-Path: <owner-freebsd-ipfw@FreeBSD.ORG>
Delivered-To: freebsd-ipfw@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9C83B16A4CE; Wed, 25 Aug 2004 11:40:14 +0000 (GMT)
Received: from shellma.zin.lublin.pl (shellma.zin.lublin.pl [212.182.126.68])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 53C6343D2D; Wed, 25 Aug 2004 11:40:14 +0000 (GMT)
	(envelope-from pawmal-posting@freebsd.lublin.pl)
Received: by shellma.zin.lublin.pl (Postfix, from userid 1018)
	id 5CE293474C2; Wed, 25 Aug 2004 13:38:22 +0200 (CEST)
Date: Wed, 25 Aug 2004 13:38:22 +0200
From: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
To: Maxime Henrion <mux@freebsd.org>
Message-ID: <20040825113822.GC57463@shellma.zin.lublin.pl>
References: <20040825110455.GB57463@shellma.zin.lublin.pl>
	<20040825111911.GE92931@elvis.mu.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <20040825111911.GE92931@elvis.mu.org>
User-Agent: Mutt/1.4.2i
cc: ipfw@freebsd.org
Subject: Re: (not) Protecting of case IP_FW_GET.
X-BeenThere: freebsd-ipfw@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: IPFW Technical Discussions <freebsd-ipfw.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-ipfw>
List-Post: <mailto:freebsd-ipfw@freebsd.org>
List-Help: <mailto:freebsd-ipfw-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw>,
	<mailto:freebsd-ipfw-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2004 11:40:14 -0000

On Wed, Aug 25, 2004 at 01:19:11PM +0200, Maxime Henrion wrote:

> > Another thing, in HEAD, there are three mallocs with M_WAITOK flag, only
> > one of them checks if malloc succeed (lookup tables code) and returns
> > ENOMEM, if not. Another two are assuming malloc will always succeed.
> > In RELENG_4, result is checked and ENOBUFS (why not ENOMEM?) is returned
> > if malloc failed.
> 
> The case where it checks the return value of malloc() is wrong.  When
> called with the M_WAITOK flag, malloc() is not supposed to return NULL.

malloc(9) states that. What would happen, if one tries to malloc more
memory than we physically have, with M_WAITOK flag -- will it eat all
available memory and wait forever for more?


-- 
Paweł Małachowski