The desync is real. The early return skipped abo->assigned_hwctx, so a command that firmware went on to complete could leave the BO attached in firmware while the driver believed it unassigned, and DETACH is refused in that state. v2 records the BO as attached when the wait is interrupted.
The premature-free path is not there. assigned_hwctx has three consumers -- the ATTACH guard, the DETACH guard, and the hwctx lookup in amdxdna_hwctx_sync_debug_bo() -- and appears in no free or close path. The debug BO is submitted as an argument BO, so the job holds a drm_gem_object reference on it until the job is freed; its lifetime does not depend on assigned_hwctx. Taimuraz
