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?
Thanks,
Deepanshu
