On 5/13/26 04:55, Deepanshu Kartikey wrote:
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:
Revert v2's prepare_fb / cleanup_fb / plane_state changes; keep the lock acquisition inside cursor_plane_update like the original code.
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.
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.