Date: Sun, 18 Jan 2004 13:57:23 -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: <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>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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.
The culprit is almost guarenteed to be blocking in the interrupt threads
themselves or blocking in serialized multi-device-handling threads
such as some of CAM's helper threads. Blocking in either could deadlock
the system in a low memory situation.
But what people seem to have done... using M_NOWAIT with very little
regard for the side effects that occur when malloc() might then fail,
is not the right solution. If the CAM code cannot use a blocking malloc
for a critical structure allocation then it certainly can't use a
non-blocking malloc that might then fail as a workaround! Some other
solution is needed for those situations (something like the MPIPE
solution I came up with to guarentee the availability of I/O request
structures in interrupt service routines).
What it comes down to for cam_sim_alloc() is, again, the context in which
it is called. Can it be called from a serialized cam thread or an
interrupt thread in a way that could potential block I/O operations for
devices other then the one trying to attach? If so then there's a real
problem that needs to be solved. If not then M_WAITOK can be safely
used in this particular situation and the NULL case no longer needs to be
worried about.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401182157.i0ILvNQe097287>