[CHECKER] bugs in FreeBSD

[Matthew Dillon]

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