From owner-freebsd-hackers@FreeBSD.ORG Sun Jan 18 12:29:08 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id DF30A16A4CF for ; Sun, 18 Jan 2004 12:29:08 -0800 (PST) Received: from smtp.mho.com (smtp.mho.net [64.58.4.6]) by mx1.FreeBSD.org (Postfix) with SMTP id 1ACE043D1F for ; Sun, 18 Jan 2004 12:29:04 -0800 (PST) (envelope-from scottl@freebsd.org) Received: (qmail 64397 invoked by uid 1002); 18 Jan 2004 20:29:03 -0000 Received: from unknown (HELO freebsd.org) (64.58.1.252) by smtp.mho.net with SMTP; 18 Jan 2004 20:29:03 -0000 Message-ID: <400AEC20.70709@freebsd.org> Date: Sun, 18 Jan 2004 13:27:12 -0700 From: Scott Long 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 References: <20040118160802.GC32115@FreeBSD.org.ua> <200401181844.i0IIivlQ096389@apollo.backplane.com> <400AE3AB.1070102@freebsd.org> <200401181957.i0IJvFTe096883@apollo.backplane.com> In-Reply-To: <200401181957.i0IJvFTe096883@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-hackers@freebsd.org cc: Paul Twohey cc: scsi@freebsd.org Subject: Re: [CHECKER] bugs in FreeBSD X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 18 Jan 2004 20:29:09 -0000 Matthew Dillon wrote: > : > :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 > :> > : > : > :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 > > So, the question becomes: If one were to use M_WAITOK is it possible > for a cam_sim_alloc() call for driver A to stall an I/O operation > occuring on driver B ? > > It's the I/O stalls that cause memory deadlocks. Allocations that do > not cause I/O stalls on unrelated devices (e.g. your swap) will not > cause memory allocation deadlocks. > > 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 > > 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