mrsas: Fix callout locking

[markj]

Summary

callout_stop() requires the associated lock to be held.

This is a bit hacky, but I believe it's safe since the subsequent
mrsas_cmd_done() call will also acquire the SIM lock to stop a different
callout.

PR: 265484
Tested by: Jérémie Jourdin <[e-mail]>

[imp]

Are we sure that mprsas_complete_cmd is never called with the sim lock held? If we're assuming that, maybe we should assert that as well... I think globally to the function, but if that causes too much grief, at least confined to MPI2_FUNCTION_SCSI_IO_REQUEST and/or MRSAS_MPI2_FUNCTION_LD_IO_REQUEST. Ideally globally because lock not held conditionally when a function is called can be quite difficult to manage.

[markj]

In D39559#900435, @imp wrote:

Are we sure that mprsas_complete_cmd is never called with the sim lock held? If we're assuming that, maybe we should assert that as well... I think globally to the function, but if that causes too much grief, at least confined to MPI2_FUNCTION_SCSI_IO_REQUEST and/or MRSAS_MPI2_FUNCTION_LD_IO_REQUEST. Ideally globally because lock not held conditionally when a function is called can be quite difficult to manage.

I'm reasonably sure. If not, then the mrsas_cmd_done() call would already be acquiring the SIM lock recursively.

Hmm... but xpt_sim_poll() acquires the SIM lock before calling mrsas_cam_poll() -> mrsas_complete_cmd(). So the existing code is already re-locking the SIM mutex. OTOH, I think xpt_sim_poll() is only used when dumping.

[markj]

Any objections to committing this for 14.0? I'm confident in the change and at least one user reported that it fixes panics for them.

[imp]

I'm good with this going in. I agree with your analysis. There are a few limited other times xpt_sim_poll is called during late shutdown though I forget exactly when (any cam request after the scheduler stops). I think it's just for the final device shutdown though and won't cause issues