diff options
| author | Alice Ryhl <aliceryhl@google.com> | 2025-08-27 13:38:39 +0000 |
|---|---|---|
| committer | Danilo Krummrich <dakr@kernel.org> | 2025-08-28 12:40:43 +0200 |
| commit | 3c8d31b8937a7ee6e5de74f0274810b8705d77ea (patch) | |
| tree | d5eb54a59449cc8f7463e8fafbb6ac1c03bf7c85 /scripts/gdb/linux/interrupts.py | |
| parent | 69013f52b4b6782db6941f83b6ff1be123bfa9e5 (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
