kernel/linux.git/drivers/gpu/drm/virtio/virtgpu_ioctl.c, branch v6.12.80

drm/virtio: Fix return value for VIRTGPU_CONTEXT_PARAM_DEBUG_NAME

2023-11-15T01:42:16+00:00

The strncpy_from_user() returns number of copied bytes and not zero on success. The non-zero return value of ioctl is treated as error. Return zero on success instead of the number of copied bytes. Fixes: 7add80126bce ("drm/uapi: add explicit virtgpu context debug name") Signed-off-by: Dmitry Osipenko Reviewed-by: Gurchetan Singh Link: https://patchwork.freedesktop.org/patch/msgid/20231111224236.890431-1-dmitry.osipenko@collabora.com

drm/uapi: add explicit virtgpu context debug name

2023-11-11T18:31:00+00:00

There are two problems with the current method of determining the virtio-gpu debug name. 1) TASK_COMM_LEN is defined to be 16 bytes only, and this is a Linux kernel idiom (see PR_SET_NAME + PR_GET_NAME). Though, Android/FreeBSD get around this via setprogname(..)/getprogname(..) in libc. On Android, names longer than 16 bytes are common. For example, one often encounters a program like "com.android.systemui". The virtio-gpu spec allows the debug name to be up to 64 bytes, so ideally userspace should be able to set debug names up to 64 bytes. 2) The current implementation determines the debug name using whatever task initiated virtgpu. This is could be a "RenderThread" of a larger program, when we actually want to propagate the debug name of the program. To fix these issues, add a new CONTEXT_INIT param that allows userspace to set the debug name when creating a context. It takes a null-terminated C-string as the param value. The length of the string (excluding the terminator) **should** be <= 64 bytes. Otherwise, the debug_name will be truncated to 64 bytes. Link to open-source userspace: https://android-review.googlesource.com/c/platform/hardware/google/gfxstream/+/2787176 Signed-off-by: Gurchetan Singh Reviewed-by: Josh Simonot Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20231018181727.772-2-gurchetansingh@chromium.org

drm/virtio: use uint64_t more in virtio_gpu_context_init_ioctl

2023-11-11T18:19:11+00:00

drm_virtgpu_context_set_param defines both param and value to be u64s. Signed-off-by: Gurchetan Singh Reviewed-by: Josh Simonot Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20231018181727.772-1-gurchetansingh@chromium.org

drm/virtio: Refactor and optimize job submission code path

2023-06-03T01:50:40+00:00

Move virtio_gpu_execbuffer_ioctl() into separate virtgpu_submit.c file, refactoring and optimizing the code along the way to ease addition of new features to the ioctl. The optimization is done by using optimal ordering of the job's submission steps, reducing code path from the start of the ioctl to the point of pushing job to virtio queue. Job's initialization is now performed before in-fence is awaited and out-fence setup is made after sending out job to virtio. Reviewed-by: Rob Clark Reviewed-by: Emil Velikov Tested-by: Pierre-Eric Pelloux-Prayer Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230416115237.798604-2-dmitry.osipenko@collabora.com

drm/virtio: exbuf->fence_fd unmodified on interrupted wait

2023-02-06T17:10:56+00:00

An interrupted dma_fence_wait() becomes an -ERESTARTSYS returned to userspace ioctl(DRM_IOCTL_VIRTGPU_EXECBUFFER) calls, prompting to retry the ioctl(), but the passed exbuf->fence_fd has been reset to -1, making the retry attempt fail at sync_file_get_fence(). The uapi for DRM_IOCTL_VIRTGPU_EXECBUFFER is changed to retain the passed value for exbuf->fence_fd when returning anything besides a successful result from the ioctl. Fixes: 2cd7b6f08bc4 ("drm/virtio: add in/out fence support for explicit synchronization") Signed-off-by: Ryan Neph Reviewed-by: Rob Clark Reviewed-by: Dmitry Osipenko Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20230203233345.2477767-1-ryanneph@chromium.org

drm/virtio: Fix GEM handle creation UAF

2023-01-09T23:17:50+00:00

Userspace can guess the handle value and try to race GEM object creation with handle close, resulting in a use-after-free if we dereference the object after dropping the handle's reference. For that reason, dropping the handle's reference must be done *after* we are done dereferencing the object. Signed-off-by: Rob Clark Reviewed-by: Chia-I Wu Fixes: 62fb7a5e1096 ("virtio-gpu: add 3d/virgl support") Cc: stable@vger.kernel.org Signed-off-by: Dmitry Osipenko Link: https://patchwork.freedesktop.org/patch/msgid/20221216233355.542197-2-robdclark@gmail.com

virtio-gpu: fix shift wrapping bug in virtio_gpu_fence_event_create()

2022-09-23T11:16:37+00:00

The ->ring_idx_mask variable is a u64 so static checkers, Smatch in this case, complain if the BIT() is not also a u64. drivers/gpu/drm/virtio/virtgpu_ioctl.c:50 virtio_gpu_fence_event_create() warn: should '(1 << ring_idx)' be a 64 bit type? Fixes: cd7f5ca33585 ("drm/virtio: implement context init: add virtio_gpu_fence_event") Signed-off-by: Dan Carpenter Reviewed-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/YygN7jY0GdUSQSy0@kili Signed-off-by: Gerd Hoffmann

drm/virtio: Fix same-context optimization

2022-08-25T09:56:22+00:00

When VIRTGPU_EXECBUF_RING_IDX is used, we should be considering the timeline that the EB if running on rather than the global driver fence context. Fixes: 85c83ea915ed ("drm/virtio: implement context init: allocate an array of fence contexts") Signed-off-by: Rob Clark Link: http://patchwork.freedesktop.org/patch/msgid/20220812224001.2806463-1-robdclark@gmail.com Signed-off-by: Gerd Hoffmann

virtio-gpu: fix a missing check to avoid NULL dereference

2022-06-09T05:30:12+00:00

'cache_ent' could be set NULL inside virtio_gpu_cmd_get_capset() and it will lead to a NULL dereference by a lately use of it (i.e., ptr = cache_ent->caps_cache). Fix it with a NULL check. Fixes: 62fb7a5e10962 ("virtio-gpu: add 3d/virgl support") Signed-off-by: Xiaomeng Tong Reviewed-by: Chia-I Wu Link: http://patchwork.freedesktop.org/patch/msgid/20220327050945.1614-1-xiam0nd.tong@gmail.com [ kraxel: minor codestyle fixup ] Signed-off-by: Gerd Hoffmann

dma-buf: add enum dma_resv_usage v4

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

This change adds the dma_resv_usage enum and allows us to specify why a dma_resv object is queried for its containing fences. Additional to that a dma_resv_usage_rw() helper function is added to aid retrieving the fences for a read or write userspace submission. This is then deployed to the different query functions of the dma_resv object and all of their users. When the write paratermer was previously true we now use DMA_RESV_USAGE_WRITE and DMA_RESV_USAGE_READ otherwise. v2: add KERNEL/OTHER in separate patch v3: some kerneldoc suggestions by Daniel v4: some more kerneldoc suggestions by Daniel, fix missing cases lost in the rebase pointed out by Bas. Signed-off-by: Christian König Reviewed-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/20220407085946.744568-2-christian.koenig@amd.com