summaryrefslogtreecommitdiff
path: root/scripts/gdb/linux/interrupts.py
diff options
context:
space:
mode:
authorAlice Ryhl <aliceryhl@google.com>2025-08-27 13:38:39 +0000
committerDanilo Krummrich <dakr@kernel.org>2025-08-28 12:40:43 +0200
commit3c8d31b8937a7ee6e5de74f0274810b8705d77ea (patch)
treed5eb54a59449cc8f7463e8fafbb6ac1c03bf7c85 /scripts/gdb/linux/interrupts.py
parent69013f52b4b6782db6941f83b6ff1be123bfa9e5 (diff)
gpuvm: remove gem.gpuva.lock_dep_map
Since all users of gem.gpuva.lock_dep_map now rely on the mutex directly in gpuva, we may remove it. Whether the mutex is used is now tracked by a flag in gpuvm rather than by whether lock_dep_map is null. Note that a GEM object may not be pushed to multiple gpuvms that disagree on the value of this new flag. But that's okay because a single driver should use the same locking scheme everywhere, and a GEM object is driver specific (when a GEM is exported with prime, a new GEM object instance is created from the backing dma-buf). The flag is present even with CONFIG_LOCKDEP=n because the intent is that the flag will also cause vm_bo cleanup to become deferred. However, that will happen in a follow-up patch. Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://lore.kernel.org/r/20250827-gpuva-mutex-in-gem-v3-3-bd89f5a82c0d@google.com [ Use lockdep_is_held() instead of lock_is_held(). - Danilo ] Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Diffstat (limited to 'scripts/gdb/linux/interrupts.py')
0 files changed, 0 insertions, 0 deletions