[CHECKER] bugs in FreeBSD

Matthew Dillon dillon at apollo.backplane.com
Sun Jan 18 13:57:26 PST 2004


:>     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 at 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 at backplane.com>


More information about the freebsd-scsi mailing list