[CHECKER] bugs in FreeBSD

[Scott Long]

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

CAM doesn't use a kthread in 4.x.  It uses it's own SWI hooks.  If you
call splcam(), then you will block those from running, and no CAM I/O
will complete until you call splx().  That's why I say that it's ok to
use M_WAITOK so long as you don't block CAM from running.

If you want to add a WAITOK/NOWAIT flag parameter to cam_sim_alloc(),
that might be a good solution.

Scott