kernel/linux.git/drivers/gpu/drm/vmwgfx, branch v6.1.38

drm/vmwgfx: Fix Legacy Display Unit atomic drm support

2023-05-17T09:53:27+00:00

[ Upstream commit a37a512db3fa1b65fe9087003e5b2072cefb3667 ] Legacy Display Unit (LDU) fb dirty support used a custom fb dirty callback. Latter handled only the DIRTYFB IOCTL presentation path but not the ADDFB2/PAGE_FLIP/RMFB IOCTL path, common for Wayland compositors. Get rid of the custom callback in favor of drm_atomic_helper_dirtyfb and unify the handling of the presentation paths inside of vmw_ldu_primary_plane_atomic_update. This also homogenizes the fb dirty callbacks across all DUs: LDU, SOU and STDU. Signed-off-by: Martin Krastev Reviewed-by: Maaz Mombasawala Fixes: 2f5544ff0300 ("drm/vmwgfx: Use atomic helper function for dirty fb IOCTL") Cc: # v5.0+ Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20230321020949.335012-3-zack@kde.org Signed-off-by: Sasha Levin

drm/vmwgfx: Remove explicit and broken vblank handling

2023-05-17T09:53:27+00:00

[ Upstream commit 2e10cdc6e85de5998b0b140deff01765ceb92f64 ] The explicit vblank handling was never finished. The driver never had the full implementation of vblank and what was there is emulated by DRM when the driver doesn't pretend to be implementing it itself. Let DRM handle the vblank emulation and stop pretending the driver is doing anything special with vblank. In the future it would make sense to implement helpers for full vblank handling because vkms and amdgpu_vkms already have that code. Exporting it to common helpers and having all three drivers share it would make sense (that would be largely just to allow more of igt to run). Signed-off-by: Zack Rusin Reviewed-by: Maaz Mombasawala Reviewed-by: Martin Krastev Reviewed-by: Michael Banack Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-15-zack@kde.org Stable-dep-of: a37a512db3fa ("drm/vmwgfx: Fix Legacy Display Unit atomic drm support") Signed-off-by: Sasha Levin

drm/vmwgfx: Do not drop the reference to the handle too soon

2023-02-22T11:59:47+00:00

commit a950b989ea29ab3b38ea7f6e3d2540700a3c54e8 upstream. v3: Fix vmw_user_bo_lookup which was also dropping the gem reference before the kernel was done with buffer depending on userspace doing the right thing. Same bug, different spot. It is possible for userspace to predict the next buffer handle and to destroy the buffer while it's still used by the kernel. Delay dropping the internal reference on the buffers until kernel is done with them. Instead of immediately dropping the gem reference in vmw_user_bo_lookup and vmw_gem_object_create_with_handle let the callers decide when they're ready give the control back to userspace. Also fixes the second usage of vmw_gem_object_create_with_handle in vmwgfx_surface.c which wasn't grabbing an explicit reference to the gem object which could have been destroyed by the userspace on the owning surface at any point. Signed-off-by: Zack Rusin Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Martin Krastev Reviewed-by: Maaz Mombasawala Link: https://patchwork.freedesktop.org/patch/msgid/20230211050514.2431155-1-zack@kde.org (cherry picked from commit 9ef8d83e8e25d5f1811b3a38eb1484f85f64296c) Cc: # v5.17+ Signed-off-by: Greg Kroah-Hartman

drm/vmwgfx: Stop accessing buffer objects which failed init

2023-02-22T11:59:47+00:00

commit 1a6897921f52ceb2c8665ef826e405bd96385159 upstream. ttm_bo_init_reserved on failure puts the buffer object back which causes it to be deleted, but kfree was still being called on the same buffer in vmw_bo_create leading to a double free. After the double free the vmw_gem_object_create_with_handle was setting the gem function objects before checking the return status of vmw_bo_create leading to null pointer access. Fix the entire path by relaying on ttm_bo_init_reserved to delete the buffer objects on failure and making sure the return status is checked before setting the gem function objects on the buffer object. Signed-off-by: Zack Rusin Fixes: 8afa13a0583f ("drm/vmwgfx: Implement DRIVER_GEM") Reviewed-by: Maaz Mombasawala Reviewed-by: Martin Krastev Link: https://patchwork.freedesktop.org/patch/msgid/20230208180050.2093426-1-zack@kde.org (cherry picked from commit 36d421e632e9a0e8375eaed0143551a34d81a7e3) Cc: # v5.17+ Signed-off-by: Greg Kroah-Hartman

treewide: fix up files incorrectly marked executable

2023-02-01T07:34:49+00:00

[ Upstream commit 262b42e02d1e0b5ad1b33e9b9842e178c16231de ] I'm not exactly clear on what strange workflow causes people to do it, but clearly occasionally some files end up being committed as executable even though they clearly aren't. This is a reprise of commit 90fda63fa115 ("treewide: fix up files incorrectly marked executable"), just with a different set of files (but with the same trivial shell scripting). So apparently we need to re-do this every five years or so, and Joe needs to just keep reminding me to do so ;) Reported-by: Joe Perches Fixes: 523375c943e5 ("drm/vmwgfx: Port vmwgfx to arm64") Fixes: 5c439937775d ("ASoC: codecs: add support for ES8326") Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin

drm/vmwgfx: Remove rcu locks from user resources

2023-01-18T10:58:28+00:00

[ Upstream commit a309c7194e8a2f8bd4539b9449917913f6c2cd50 ] User resource lookups used rcu to avoid two extra atomics. Unfortunately the rcu paths were buggy and it was easy to make the driver crash by submitting command buffers from two different threads. Because the lookups never show up in performance profiles replace them with a regular spin lock which fixes the races in accesses to those shared resources. Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and seen crashes with apps using shared resources. Fixes: e14c02e6b699 ("drm/vmwgfx: Look up objects without taking a reference") Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Reviewed-by: Maaz Mombasawala Link: https://patchwork.freedesktop.org/patch/msgid/20221207172907.959037-1-zack@kde.org Signed-off-by: Sasha Levin

drm/vmwgfx: Remove vmwgfx_hashtab

2023-01-18T10:58:28+00:00

[ Upstream commit 9da30cdd6a318595199319708c143ae318f804ef ] The vmwgfx driver has migrated from using the hashtable in vmwgfx_hashtab to the linux/hashtable implementation. Remove the vmwgfx_hashtab from the driver. Signed-off-by: Maaz Mombasawala Reviewed-by: Martin Krastev Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-12-zack@kde.org Stable-dep-of: a309c7194e8a ("drm/vmwgfx: Remove rcu locks from user resources") Signed-off-by: Sasha Levin

drm/vmwgfx: Refactor ttm reference object hashtable to use linux/hashtable.

2023-01-18T10:58:28+00:00

[ Upstream commit 76a9e07f270cf5fb556ac237dbf11f5dacd61fef ] This is part of an effort to move from the vmwgfx_open_hash hashtable to linux/hashtable implementation. Refactor the ref_hash hashtable, used for fast lookup of reference objects associated with a ttm file. This also exposed a problem related to inconsistently using 32-bit and 64-bit keys with this hashtable. The hash function used changes depending on the size of the type, and results are not consistent across numbers, for example, hash_32(329) = 329, but hash_long(329) = 328. This would cause the lookup to fail for objects already in the hashtable, since keys of different sizes were being passed during adding and lookup. This was not an issue before because vmwgfx_open_hash always used hash_long. Fix this by always using 64-bit keys for this hashtable, which means that hash_long is always used. Signed-off-by: Maaz Mombasawala Reviewed-by: Zack Rusin Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-11-zack@kde.org Stable-dep-of: a309c7194e8a ("drm/vmwgfx: Remove rcu locks from user resources") Signed-off-by: Sasha Levin

drm/vmwgfx: Refactor resource validation hashtable to use linux/hashtable implementation.

2023-01-18T10:58:28+00:00

[ Upstream commit 9e931f2e09701e25744f3d186a4ba13b5342b136 ] Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable to reduce maintenence burden. As part of this effort, refactor the res_ht hashtable used for resource validation during execbuf execution to use linux/hashtable implementation. This also refactors vmw_validation_context to use vmw_sw_context as the container for the hashtable, whereas before it used a vmwgfx_open_hash directly. This makes vmw_validation_context less generic, but there is no functional change since res_ht is the only instance where validation context used a hashtable in vmwgfx driver. Signed-off-by: Maaz Mombasawala Reviewed-by: Thomas Hellström Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-6-zack@kde.org Stable-dep-of: a309c7194e8a ("drm/vmwgfx: Remove rcu locks from user resources") Signed-off-by: Sasha Levin

drm/vmwgfx: Remove ttm object hashtable

2023-01-18T10:58:28+00:00

[ Upstream commit 931e09d8d5b4aa19bdae0234f2727049f1cd13d9 ] The object_hash hashtable for ttm objects is not being used. Remove it and perform refactoring in ttm_object init function. Signed-off-by: Maaz Mombasawala Reviewed-by: Zack Rusin Reviewed-by: Martin Krastev Signed-off-by: Zack Rusin Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-5-zack@kde.org Stable-dep-of: a309c7194e8a ("drm/vmwgfx: Remove rcu locks from user resources") Signed-off-by: Sasha Levin