From owner-freebsd-scsi@FreeBSD.ORG  Sun Jan 18 11:53:05 2004
Return-Path: <owner-freebsd-scsi@FreeBSD.ORG>
Delivered-To: freebsd-scsi@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 1589B16A4CE
	for <scsi@freebsd.org>; Sun, 18 Jan 2004 11:53:05 -0800 (PST)
Received: from smtp.mho.com (smtp.mho.net [64.58.4.6])
	by mx1.FreeBSD.org (Postfix) with SMTP id 5055B43D5C
	for <scsi@freebsd.org>; Sun, 18 Jan 2004 11:53:00 -0800 (PST)
	(envelope-from scottl@freebsd.org)
Received: (qmail 63113 invoked by uid 1002); 18 Jan 2004 19:52:57 -0000
Received: from unknown (HELO freebsd.org) (64.58.1.252)
  by smtp.mho.net with SMTP; 18 Jan 2004 19:52:57 -0000
Message-ID: <400AE3AB.1070102@freebsd.org>
Date: Sun, 18 Jan 2004 12:51:07 -0700
From: Scott Long <scottl@freebsd.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.5) Gecko/20031103
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Matthew Dillon <dillon@apollo.backplane.com>
References: <Pine.LNX.4.44.0401161607260.26554-100000@Xenon.Stanford.EDU>
	<20040118160802.GC32115@FreeBSD.org.ua>
	<200401181844.i0IIivlQ096389@apollo.backplane.com>
In-Reply-To: <200401181844.i0IIivlQ096389@apollo.backplane.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: freebsd-hackers@freebsd.org
cc: Paul Twohey <twohey@CS.Stanford.EDU>
cc: Ruslan Ermilov <ru@freebsd.org>
cc: scsi@freebsd.org
Subject: Re: [CHECKER] bugs in FreeBSD
X-BeenThere: freebsd-scsi@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: SCSI subsystem <freebsd-scsi.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-scsi>,
	<mailto:freebsd-scsi-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-scsi>
List-Post: <mailto:freebsd-scsi@freebsd.org>
List-Help: <mailto:freebsd-scsi-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-scsi>,
	<mailto:freebsd-scsi-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Jan 2004 19:53:05 -0000

Matthew Dillon wrote:
>      These cam_sim_alloc() calls seem to be fairly critical to the operation
>      of DPT and friends, why is it even possible for them to return NULL
>      in the first place and what would be the effect of a (properly handled)
>      NULL return if it did occur at this point?
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@backplane.com>


cam_sim_alloc() is vital to the operation of any CAM driver.  However,
cam_sim_alloc() mallocs it's data structures with the M_NOWAIT flag, so
it is possible for it to fail and have to return NULL.  The reason it 
uses the M_NOWAIT flag is because there is no restrictions on when
driver attach events happen, though they all happen in normal process
or kthread context these days (except at boot, but if you have to sleep
for memory during boot, you have a lot of other problems).


Scott