Date: Sun, 18 Jan 2004 11:57:15 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Scott Long <scottl@freebsd.org> Cc: scsi@freebsd.org Subject: Re: [CHECKER] bugs in FreeBSD Message-ID: <200401181957.i0IJvFTe096883@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>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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
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
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401181957.i0IJvFTe096883>