From owner-freebsd-scsi@FreeBSD.ORG  Sun Jan 18 14:08:50 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 1ACEE16A4CE
	for <scsi@FreeBSD.org>; Sun, 18 Jan 2004 14:08:50 -0800 (PST)
Received: from smtp.mho.com (smtp.mho.net [64.58.4.6])
	by mx1.FreeBSD.org (Postfix) with SMTP id 2212743D6A
	for <scsi@FreeBSD.org>; Sun, 18 Jan 2004 14:08:38 -0800 (PST)
	(envelope-from scottl@freebsd.org)
Received: (qmail 69148 invoked by uid 1002); 18 Jan 2004 22:08:37 -0000
Received: from unknown (HELO freebsd.org) (64.58.1.252)
  by smtp.mho.net with SMTP; 18 Jan 2004 22:08:37 -0000
Message-ID: <400B0377.4070405@freebsd.org>
Date: Sun, 18 Jan 2004 15:06:47 -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>
	<400AE3AB.1070102@freebsd.org>
	<200401181957.i0IJvFTe096883@apollo.backplane.com>
	<400AEC20.70709@freebsd.org>
	<200401182157.i0ILvNQe097287@apollo.backplane.com>
In-Reply-To: <200401182157.i0ILvNQe097287@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 22:08:50 -0000

Matthew Dillon wrote:
> :>     I know cam uses some helper threads so I am not entirely sure about
> :>     the context the cam_sim_alloc() calls are being made in, but if they
> :>     do not create I/O stalls for already-operational SCSI devices then I
> :>     am inclined (in DFly anyway) to simply make the malloc in
> :>     cam_sim_alloc() M_WAITOK.
> :> 
> :> 					-Matt
> :> 					Matthew Dillon 
> :> 					<dillon@backplane.com>
> :> 
> :
> :In the 4.x case, so long as the driver doesn't do an splcam() or somehow
> :block hardware interrupts before calling cam_sim_alloc() you are
> :probably fine.  For 5.x, you might run into Giant problems.
> :
> :Scott
> 
>     Well, I don't see how a spl or Giant could possibly have anything to
>     do with memory deadlocks.  Both are dropped when a thread blocks so the
>     worst that happens is that you add some latency.

CAM doesn't use a kthread in 4.x.  It uses it's own SWI hooks.  If you
call splcam(), then you will block those from running, and no CAM I/O
will complete until you call splx().  That's why I say that it's ok to
use M_WAITOK so long as you don't block CAM from running.

If you want to add a WAITOK/NOWAIT flag parameter to cam_sim_alloc(),
that might be a good solution.

Scott