On 5/13/26 04:55, Deepanshu Kartikey wrote: > On Tue, May 12, 2026 at 12:04 PM Dmitry Osipenko > <[email protected]> wrote: >> >> I'm getting lockup with this patch applied and now see that >> virtio_gpu_resource_flush() also locks BO. >> >> Easiest option might be to add uninterruptible variant of >> virtio_gpu_array_lock_resv(). Could you please try it for v3? >> >> -- >> Best regards, >> Dmitry > > Hi Dmitry, > > Thanks for testing and catching the lockup. Before I send v3, want > to confirm the approach: > > 1. Revert v2's prepare_fb / cleanup_fb / plane_state changes; > keep the lock acquisition inside cursor_plane_update like > the original code. > > 2. Add virtio_gpu_array_lock_resv_uninterruptible() in > virtgpu_gem.c, mirroring the existing helper but using > dma_resv_lock() instead of dma_resv_lock_interruptible() on > the nents==1 path. Declare it in virtgpu_drv.h. > > 3. In cursor_plane_update, call the new helper and check its > return. The signal path is closed; -ENOMEM from > dma_resv_reserve_fences() remains and is handled by freeing > objs and skipping the cursor update for that frame. > > A skipped cursor frame on ENOMEM is the remaining failure mode in > .atomic_update; this avoids the lockup with virtio_gpu_resource_flush() > that v2's broader lock scope caused. > > Does that match what you had in mind?
Sounds good. The virtio_gpu_resource_flush() also should be updated to use uninterruptible() variant. -- Best regards, Dmitry
