Hi Christian, Thanks, and sorry, my commit message was inaccurate. Dropping the queue's fence_drv reference is unrelated to fence_drv->fences, as you say.
amdgpu_userq_signal_ioctl() takes the wptr from the user mapped wptr BO and hands it to dma_fence_init64() as the seqno, which is documented as "a linear increasing sequence number for this context". Nothing on that path checks that it increases. fence_drv->fences is filled with list_add_tail() and drained by amdgpu_userq_fence_driver_process() as a sorted prefix cut, so a wptr that moves backwards leaves a fence sitting at the head of the list blocking the drain. The hang detect path does not recover it either. force_completion() takes the forced rptr from userq->last_fence->seqno, which the same regression has already moved backwards. Destroying the queue then makes it permanent: amdgpu_userq_fence_driver_process() is only reachable through a live queue. So is a userspace that moves its own wptr backwards in scope here? I can send a v2 that rejects a non-advancing wptr instead of touching the fence list. Thanks, Junrui Luo
