kernel/linux.git/drivers/gpu/drm/virtio/virtgpu_gem.c, branch v6.18.34

drm/virtio: use uninterruptible resv lock for plane updates

2026-06-01T15:50:47+00:00

commit 9af1b6e175c82daf4b423da339a722d8e67a735a upstream. virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush() lock the framebuffer BO's dma_resv via virtio_gpu_array_lock_resv() and ignore its return value. The function can fail with -EINTR from dma_resv_lock_interruptible() (signal during lock wait) or with -ENOMEM from dma_resv_reserve_fences() (fence slot allocation), leaving the resv lock not held. The queue path then walks the object array and calls dma_resv_add_fence(), which requires the lock held; with lockdep enabled this trips dma_resv_assert_held(): WARNING: drivers/dma-buf/dma-resv.c:296 at dma_resv_add_fence+0x71e/0x840 Call Trace: virtio_gpu_array_add_fence virtio_gpu_queue_ctrl_sgs virtio_gpu_queue_fenced_ctrl_buffer virtio_gpu_cursor_plane_update drm_atomic_helper_commit_planes drm_atomic_helper_commit_tail commit_tail drm_atomic_helper_commit drm_atomic_commit drm_atomic_helper_update_plane __setplane_atomic drm_mode_cursor_universal drm_mode_cursor_common drm_mode_cursor_ioctl drm_ioctl __x64_sys_ioctl Beyond the WARN, mutating the dma_resv fence list without the lock races with concurrent readers/writers and can corrupt the list. Both call sites run inside the .atomic_update plane callback, which DRM atomic helpers do not allow to fail (by the time it runs, the commit has been signed off to userspace and there is no clean rollback path). Moving the lock acquisition to .prepare_fb was rejected because the broader lock scope deadlocks against other BO locking paths in the same atomic commit. Introduce virtio_gpu_lock_one_resv_uninterruptible() that uses dma_resv_lock() instead of dma_resv_lock_interruptible(). This eliminates the -EINTR failure mode -- the realistic syzbot trigger -- without extending the lock hold across the commit. The helper locks a single BO and rejects nents > 1 with -EINVAL; both fix sites lock exactly one BO. Use it from virtio_gpu_cursor_plane_update() and virtio_gpu_resource_flush(); check the return value to handle the remaining -ENOMEM case from dma_resv_reserve_fences() by freeing the objs and skipping the plane update for that frame. The framebuffer BOs touched here are not shared with other contexts and lock contention is expected to be brief, so the loss of signal-interruptibility is acceptable. Other callers of virtio_gpu_array_lock_resv() (the ioctl paths) continue to use the interruptible variant. The bug was reported by syzbot, triggered via fault injection (fail_nth) on the DRM_IOCTL_MODE_CURSOR path, which forces the -ENOMEM branch in dma_resv_reserve_fences(). Reported-by: syzbot+72bd3dd3a5d5f39a0271@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=72bd3dd3a5d5f39a0271 Fixes: 5cfd31c5b3a3 ("drm/virtio: fix virtio_gpu_cursor_plane_update().") Cc: stable@vger.kernel.org Signed-off-by: Deepanshu Kartikey Signed-off-by: Dmitry Osipenko Link: https://patch.msgid.link/20260519082247.34470-1-kartikey406@gmail.com Signed-off-by: Greg Kroah-Hartman

Merge drm/drm-fixes into drm-misc-fixes

2025-04-08T08:15:47+00:00

Backmerging to get updates from v6.15-rc1. Signed-off-by: Thomas Zimmermann

drm/virtio: Don't attach GEM to a non-created context in gem_object_open()

2025-04-01T20:11:54+00:00

The vfpriv->ctx_id is always initialized to a non-zero value. Check whether context was created before attaching GEM to this context ID. This left unnoticed previously because host silently skips attachment if context doesn't exist, still we shouldn't do that for consistency. Fixes: 086b9f27f0ab ("drm/virtio: Don't create a context with default param if context_init is supported") Cc: # v6.14+ Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Clark Link: https://lore.kernel.org/r/20250401123842.2232205-1-dmitry.osipenko@collabora.com

drm/virtio: Add drm_panic support

2025-02-09T17:36:51+00:00

Virtio gpu supports the drm_panic module, which displays a message to the screen when a kernel panic occurs. It is supported where it has vmapped shmem BO. Signed-off-by: Jocelyn Falempe Signed-off-by: Ryosuke Yasuoka Tested-by: Dmitry Osipenko Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20250206104300.416014-1-ryasuoka@redhat.com

drm/virtio: Don't create a context with default param if context_init is supported

2024-11-18T18:17:42+00:00

Xorg context creation fails for native contexts that use VIRTGPU_CONTEXT_INIT because context is already initialized implicitly when dumb buffer is created. Fix it by not creating default vrend context if context_init is supported. Signed-off-by: Pierre-Eric Pelloux-Prayer Signed-off-by: Dmitry Osipenko Reviewed-by: Rob Clark Link: https://patchwork.freedesktop.org/patch/msgid/20241020224725.179937-1-dmitry.osipenko@collabora.com

drm/virtio: Use generic dumb_map_offset implementation

2024-11-18T11:08:37+00:00

Currently, virtio uses its own dumb_map_offset implementation, virtio_gpu_mode_dumb_mmap. It works similarly to generic implementation, drm_gem_dumb_map_offset, and using the generic implementation is preferable (and making drivers to do so is a task stated on the DRM subsystem's TODO list). Thus, make driver use the generic implementation. This includes VIRTGPU_MAP ioctl so it cannot be used to circumvent rules imposed by drm_gem_dumb_map_offset (imported objects cannot be mapped). Signed-off-by: Peter Shkenev Signed-off-by: Dmitry Osipenko [dmitry.osipenko@collabora.com: cosmetic code improvements] Link: https://patchwork.freedesktop.org/patch/msgid/20241107141133.13624-1-mustela@erminea.space

drm/virtio: Unlock reservations on dma_resv_reserve_fences() error

2022-07-19T12:40:58+00:00

Unlock reservations on dma_resv_reserve_fences() error to fix recursive locking of the reservations when this error happens. Cc: stable@vger.kernel.org Fixes: c8d4c18bfbc4 ("dma-buf/drivers: make reserving a shared slot mandatory v4") Reviewed-by: Thomas Hellström Signed-off-by: Dmitry Osipenko Link: http://patchwork.freedesktop.org/patch/msgid/20220630200726.1884320-5-dmitry.osipenko@collabora.com Signed-off-by: Gerd Hoffmann

dma-buf: specify usage while adding fences to dma_resv obj v7

2022-04-07T10:53:53+00:00

Instead of distingting between shared and exclusive fences specify the fence usage while adding fences. Rework all drivers to use this interface instead and deprecate the old one. v2: some kerneldoc comments suggested by Daniel v3: fix a missing case in radeon v4: rebase on nouveau changes, fix lockdep and temporary disable warning v5: more documentation updates v6: separate internal dma_resv changes from this patch, avoids to disable warning temporary, rebase on upstream changes v7: fix missed case in lima driver, minimize changes to i915_gem_busy_ioctl Signed-off-by: Christian König Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-3-christian.koenig@amd.com

dma-buf/drivers: make reserving a shared slot mandatory v4

2022-04-06T15:38:25+00:00

Audit all the users of dma_resv_add_excl_fence() and make sure they reserve a shared slot also when only trying to add an exclusive fence. This is the next step towards handling the exclusive fence like a shared one. v2: fix missed case in amdgpu v3: and two more radeon, rename function v4: add one more case to TTM, fix i915 after rebase Signed-off-by: Christian König Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220406075132.3263-2-christian.koenig@amd.com

drm/virtio: Ensure that objs is not NULL in virtio_gpu_array_put_free()

2022-01-18T06:52:42+00:00

If virtio_gpu_object_shmem_init() fails (e.g. due to fault injection, as it happened in the bug report by syzbot), virtio_gpu_array_put_free() could be called with objs equal to NULL. Ensure that objs is not NULL in virtio_gpu_array_put_free(), or otherwise return from the function. Cc: stable@vger.kernel.org # 5.13.x Signed-off-by: Roberto Sassu Reported-by: syzbot+e9072e90624a31dfa85f@syzkaller.appspotmail.com Fixes: 377f8331d0565 ("drm/virtio: fix possible leak/unlock virtio_gpu_object_array") Link: http://patchwork.freedesktop.org/patch/msgid/20211213183122.838119-1-roberto.sassu@huawei.com Signed-off-by: Gerd Hoffmann