kernel/linux.git/drivers/gpu/drm/vkms, branch v5.15.209

drm/vkms: Adjust vkms_state->active_planes allocation type

2025-06-27T10:05:11+00:00

[ Upstream commit 258aebf100540d36aba910f545d4d5ddf4ecaf0b ] In preparation for making the kmalloc family of allocators type aware, we need to make sure that the returned type from the allocation matches the type of the variable being assigned. (Before, the allocator would always return "void *", which can be implicitly cast to any pointer type.) The assigned type is "struct vkms_plane_state **", but the returned type will be "struct drm_plane **". These are the same size (pointer size), but the types don't match. Adjust the allocation type to match the assignment. Signed-off-by: Kees Cook Reviewed-by: Louis Chauvet Fixes: 8b1865873651 ("drm/vkms: totally reworked crc data tracking") Link: https://lore.kernel.org/r/20250426061431.work.304-kees@kernel.org Signed-off-by: Louis Chauvet Signed-off-by: Sasha Levin

drm/vkms: Fix use after free and double free on init error

2025-04-10T12:31:58+00:00

[ Upstream commit ed15511a773df86205bda66c37193569575ae828 ] If the driver initialization fails, the vkms_exit() function might access an uninitialized or freed default_config pointer and it might double free it. Fix both possible errors by initializing default_config only when the driver initialization succeeded. Reported-by: Louis Chauvet Closes: https://lore.kernel.org/all/Z5uDHcCmAwiTsGte@louis-chauvet-laptop/ Fixes: 2df7af93fdad ("drm/vkms: Add vkms_config type") Signed-off-by: José Expósito Reviewed-by: Thomas Zimmermann Reviewed-by: Louis Chauvet Link: https://patchwork.freedesktop.org/patch/msgid/20250212084912.3196-1-jose.exposito89@gmail.com Signed-off-by: Louis Chauvet Signed-off-by: Sasha Levin

drm/vkms: Fix null-ptr-deref in vkms_release()

2023-03-10T08:39:20+00:00

[ Upstream commit 2fe2a8f40c21161ffe7653cc234e7934db5b7cc5 ] A null-ptr-deref is triggered when it tries to destroy the workqueue in vkms->output.composer_workq in vkms_release(). KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 5 PID: 17193 Comm: modprobe Not tainted 6.0.0-11331-gd465bff130bf #24 RIP: 0010:destroy_workqueue+0x2f/0x710 ... Call Trace: ? vkms_config_debugfs_init+0x50/0x50 [vkms] __devm_drm_dev_alloc+0x15a/0x1c0 [drm] vkms_init+0x245/0x1000 [vkms] do_one_initcall+0xd0/0x4f0 do_init_module+0x1a4/0x680 load_module+0x6249/0x7110 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that an OOM happened which triggers the destroy of the workqueue, however, the workqueue is alloced in the later process, thus a null-ptr-deref happened. A simple call graph is shown as below: vkms_init() vkms_create() devm_drm_dev_alloc() __devm_drm_dev_alloc() devm_drm_dev_init() devm_add_action_or_reset() devm_add_action() # an error happened devm_drm_dev_init_release() drm_dev_put() kref_put() drm_dev_release() vkms_release() destroy_workqueue() # null-ptr-deref happened vkms_modeset_init() vkms_output_init() vkms_crtc_init() # where the workqueue get allocated Fix this by checking if composer_workq is NULL before passing it to the destroy_workqueue() in vkms_release(). Fixes: 6c234fe37c57 ("drm/vkms: Implement CRC debugfs API") Signed-off-by: Yuan Can Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20221101065156.41584-3-yuancan@huawei.com Signed-off-by: Sasha Levin

drm/vkms: Fix memory leak in vkms_init()

2023-03-10T08:39:20+00:00

[ Upstream commit 0d0b368b9d104b437e1f4850ae94bdb9a3601e89 ] A memory leak was reported after the vkms module install failed. unreferenced object 0xffff88810bc28520 (size 16): comm "modprobe", pid 9662, jiffies 4298009455 (age 42.590s) hex dump (first 16 bytes): 01 01 00 64 81 88 ff ff 00 00 dc 0a 81 88 ff ff ...d............ backtrace: [<00000000e7561ff8>] kmalloc_trace+0x27/0x60 [<000000000b1954a0>] 0xffffffffc45200a9 [<00000000abbf1da0>] do_one_initcall+0xd0/0x4f0 [<000000001505ee87>] do_init_module+0x1a4/0x680 [<00000000958079ad>] load_module+0x6249/0x7110 [<00000000117e4696>] __do_sys_finit_module+0x140/0x200 [<00000000f74b12d2>] do_syscall_64+0x35/0x80 [<000000008fc6fcde>] entry_SYSCALL_64_after_hwframe+0x46/0xb0 The reason is that the vkms_init() returns without checking the return value of vkms_create(), and if the vkms_create() failed, the config allocated at the beginning of vkms_init() is leaked. vkms_init() config = kmalloc(...) # config allocated ... return vkms_create() # vkms_create failed and config is leaked Fix this problem by checking return value of vkms_create() and free the config if error happened. Fixes: 2df7af93fdad ("drm/vkms: Add vkms_config type") Signed-off-by: Yuan Can Reviewed-by: Melissa Wen Signed-off-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20221101065156.41584-2-yuancan@huawei.com Signed-off-by: Sasha Levin

drm/vkms: Use offset-adjusted shadow-plane mappings and output

2021-08-08T18:27:52+00:00

For framebuffers with non-zero offset fields, shadow-plane helpers provide a pointer to the first byte of the contained data. Use it in vkms. Also provide use the offset-adjusted data address for the writeback job's output buffers. Output framebuffers with non-zero offsets now have their content written to the correct location. Signed-off-by: Thomas Zimmermann Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210803125928.27780-12-tzimmermann@suse.de

drm/gem: Provide offset-adjusted framebuffer BO mappings

2021-08-08T18:26:16+00:00

Add an additional argument to drm_gem_fb_vmap() to return each BO's mapping adjusted by the respective offset. Update all callers. The newly returned values point to the first byite of the data stored in the framebuffer BOs. Drivers that access the BO data should use it. Signed-off-by: Thomas Zimmermann Reviewed-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210803125928.27780-2-tzimmermann@suse.de

drm/vkms: Map output framebuffer BOs with drm_gem_fb_vmap()

2021-08-02T14:41:20+00:00

Abstract the framebuffer details by mappings its BOs with a call to drm_gem_fb_vmap(). Unmap with drm_gem_fb_vunamp(). Before, the output address with stored as raw pointer in the priv field of struct drm_writeback_job. Introduce the new type struct vkms_writeback_job, which holds the output mappings addresses while the writeback job is active. The patchset also cleans up some internal casting an setup of the output addresses. No functional changes. v3: * free instances of struct vkms_writeback_job on cleanup or errors Signed-off-by: Thomas Zimmermann Reviewed-by: Rodrigo Siqueira Acked-by: Sam Ravnborg Link: https://patchwork.freedesktop.org/patch/msgid/20210730183511.20080-6-tzimmermann@suse.de

drm/vkms: Use dma-buf mapping from shadow-plane state for composing

2021-07-13T11:36:21+00:00

Store the shadow-buffer mapping's address in struct vkms_composer and use the value when composing the output. It's the same value as stored in the GEM SHMEM BO, but frees the composer code from its dependency on GEM SHMEM. Using struct dma_buf_map is how framebuffer access is supposed to be. The long-term plan is to perform all framebuffer access via struct dma_buf_map and avoid the details of accessing I/O and system memory. Signed-off-by: Thomas Zimmermann Reviewed-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20210705074633.9425-5-tzimmermann@suse.de

drm/vkms: Let shadow-plane helpers prepare the plane's FB

2021-07-13T11:31:08+00:00

Replace vkms' prepare_fb and cleanup_fb functions with the generic code for shadow-buffered planes. No functional changes. This change also fixes a problem where IGT kms_flip tests would create a segmentation fault within vkms. The driver's prepare_fb function did not report an error if a BO's vmap operation failed. The kernel later tried to operate on the non-mapped memory areas. The shared shadow-plane helpers handle errors correctly, so that the driver now avoids the segmantation fault. v2: * include paragraph about IGT tests in commit message (Melissa) Signed-off-by: Thomas Zimmermann Reviewed-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20210705074633.9425-4-tzimmermann@suse.de

drm/vkms: Inherit plane state from struct drm_shadow_plane_state

2021-07-13T11:31:05+00:00

Subclass struct drm_shadow_plane_state for VKMS planes and update all plane-state callbacks accordingly. Signed-off-by: Thomas Zimmermann Reviewed-by: Melissa Wen Link: https://patchwork.freedesktop.org/patch/msgid/20210705074633.9425-3-tzimmermann@suse.de