iscsi(4) freeze vs action race workaround

[trasz]

Summary

If the SIM freezes the queue at exactly the wrong moment, after
another thread has started to send in a CCB and already checked
the queue wasn't frozen, we would end up with iscsi_action()
being called despite the queue is now frozen.

Add a check to make sure this doesn't happen. Perhaps this should
be fixed at the CAM level instead, but given how the send queue
and SIM are governed by two separate mutexes, it could be somewhat
hard to do.

[mav]

It seems like a real race window, opened by my fine-grained locking years ago. The freeze is protected by devq->send_mtx, while the driver code is not protected by it, protected either by SIM lock, or possibly nothing at all. So for this specific driver your solution seems correct. For general case though it is more difficult.

[imp]

There's many races here around frozen queues, and I'll wager it's best to check the race is lost in the sim like this rather than introduce a new lock that would contend.

Though having said that. Scott is making the case that the whole recovery model needs a good overhaul give the diversity of practice in existing SIMs.

[trasz]

(Tinderboxed.)