summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/git@git.tavy.me:linux-stable.git
diff options
context:
space:
mode:
authorAlice Ryhl <aliceryhl@google.com>2026-01-08 16:07:31 +0000
committerDanilo Krummrich <dakr@kernel.org>2026-01-08 17:45:09 +0100
commit9ce4aef9a5b1b76207152ba019f838f62dff97b8 (patch)
tree1426e82fffb9c9f3c8965b457236b7282d056770 /tools/perf/scripts/python/git@git.tavy.me:linux-stable.git
parent7f6721b767e219343cfe9a894f5bd869ff5b9d3a (diff)
drm/gpuvm: take GEM lock inside drm_gpuvm_bo_obtain_prealloc()
When calling drm_gpuvm_bo_obtain_prealloc() and using immediate mode, this may result in a call to ops->vm_bo_free(vm_bo) while holding the GEMs gpuva mutex. This is a problem if ops->vm_bo_free(vm_bo) performs any operations that are not safe in the fence signalling critical path, and it turns out that Panthor (the only current user of the method) calls drm_gem_shmem_unpin() which takes a resv lock internally. This constitutes both a violation of signalling safety and lock inversion. To fix this, we modify the method to internally take the GEMs gpuva mutex so that the mutex can be unlocked before freeing the preallocated vm_bo. Note that this modification introduces a requirement that the driver uses immediate mode to call drm_gpuvm_bo_obtain_prealloc() as it would otherwise take the wrong lock. Fixes: 63e919a31625 ("panthor: use drm_gpuva_unlink_defer()") Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260108-gpuvm-rust-v2-1-dbd014005a0b@google.com Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Diffstat (limited to 'tools/perf/scripts/python/git@git.tavy.me:linux-stable.git')
0 files changed, 0 insertions, 0 deletions