On Tue, May 12, 2026 at 12:04 PM Dmitry Osipenko dmitry.osipenko@collabora.com 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?
Thanks, Deepanshu