[CHECKER] bugs in FreeBSD

[Scott Long]

Matthew Dillon wrote:
> :
> :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>
> 

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