This makes the wait survivable but leaves the lock cycle in place: both
callers hold dev_lock across aie2_cmd_wait(), and aie2_sched_job_timedout()
needs that same lock before it can force the fence to signal.

The wait itself does not need the lock. aie2_cmd_get_out_fence() already
returns a referenced fence and drv_cmd is krefed, so the sequence could be:
submit and take the fence under dev_lock, drop the lock, wait, retake it.
Nothing after the wait touches hwctx. amdxdna_pm_resume_get_locked() and
amdxdna_update_heap() already drop a caller's lock this way, so the shape is
not new to this driver.

The alternative is to change the op contract instead: have hwctx_config() and
hwctx_sync_debug_bo() return once the command is submitted and let the ioctl
do the waiting, which keeps the lock discipline in one place.

Which of the two would you rather see? I have not been able to reproduce a
debug BO command that does not complete, so I would rather ask than guess at
the invariants that have to hold across the unlocked window.

Taimuraz

Reply via email to