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

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

drm/vmwgfx: Refactor resource manager's hashtable to use linux/hashtable implementation.

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

[ Upstream commit 43531dc661b7fb6be249c023bf25847b38215545 ] Vmwgfx's hashtab implementation needs to be replaced with linux/hashtable to reduce maintenance burden. Refactor cmdbuf resource manager to use linux/hashtable.h implementation as part of this effort. 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-4-zack@kde.org Stable-dep-of: a309c7194e8a ("drm/vmwgfx: Remove rcu locks from user resources") Signed-off-by: Sasha Levin

drm/vmwgfx: Write the driver id registers

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

[ Upstream commit 7f4c33778686cc2d34cb4ef65b4265eea874c159 ] Driver id registers are a new mechanism in the svga device to hint to the device which driver is running. This should not change device behavior in any way, but might be convenient to work-around specific bugs in guest drivers. Signed-off-by: Zack Rusin Reviewed-by: Martin Krastev Reviewed-by: Maaz Mombasawala Link: https://patchwork.freedesktop.org/patch/msgid/20221022040236.616490-2-zack@kde.org Stable-dep-of: a309c7194e8a ("drm/vmwgfx: Remove rcu locks from user resources") Signed-off-by: Sasha Levin