From owner-freebsd-ipfw@FreeBSD.ORG  Fri Oct  8 06:09:55 2004
Return-Path: <owner-freebsd-ipfw@FreeBSD.ORG>
Delivered-To: freebsd-ipfw@freebsd.org
Received: from green.homeunix.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP
	id A40ED16A4CF; Fri,  8 Oct 2004 06:09:54 +0000 (GMT)
Received: from green.homeunix.org (green@localhost [127.0.0.1])
	by green.homeunix.org (8.13.1/8.13.1) with ESMTP id i9869sGp001858;
	Fri, 8 Oct 2004 02:09:54 -0400 (EDT)
	(envelope-from green@green.homeunix.org)
Received: (from green@localhost)
	by green.homeunix.org (8.13.1/8.13.1/Submit) id i9869pPB001857;
	Fri, 8 Oct 2004 02:09:51 -0400 (EDT)
	(envelope-from green)
Date: Fri, 8 Oct 2004 02:09:51 -0400
From: Brian Fundakowski Feldman <green@freebsd.org>
To: Pawel Malachowski <pawmal-posting@freebsd.lublin.pl>
Message-ID: <20041008060950.GA980@green.homeunix.org>
References: <20040825110455.GB57463@shellma.zin.lublin.pl>
	<20040825111911.GE92931@elvis.mu.org>
	<20040825113822.GC57463@shellma.zin.lublin.pl>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20040825113822.GC57463@shellma.zin.lublin.pl>
User-Agent: Mutt/1.5.6i
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: Fri, 08 Oct 2004 06:09:55 -0000

On Wed, Aug 25, 2004 at 01:38:22PM +0200, Pawel Malachowski wrote:
> 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?

No, it would crash the kernel.  You are only supposed to make "reasonable"
request for memory.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green@FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\