Date: Sun, 18 Jan 2004 15:06:47 -0700 From: Scott Long <scottl@freebsd.org> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: scsi@FreeBSD.org Subject: Re: [CHECKER] bugs in FreeBSD Message-ID: <400B0377.4070405@freebsd.org> In-Reply-To: <200401182157.i0ILvNQe097287@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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?400B0377.4070405>