diff options
| author | Alice Ryhl <aliceryhl@google.com> | 2025-10-06 12:05:55 +0000 |
|---|---|---|
| committer | Alice Ryhl <aliceryhl@google.com> | 2025-10-20 11:24:52 +0000 |
| commit | 8e4865faf7a97de2a0fd797556a62b31528b42bc (patch) | |
| tree | 5146abaa2feffbbf049c71985b3ec4dd0a34b6a7 /rust/kernel | |
| parent | 1d5cffebd930d61588c32198f85fbe541ab97b8f (diff) | |
drm/gpuvm: add deferred vm_bo cleanup
When using GPUVM in immediate mode, it is necessary to call
drm_gpuvm_unlink() from the fence signalling critical path. However,
unlink may call drm_gpuvm_bo_put(), which causes some challenges:
1. drm_gpuvm_bo_put() often requires you to take resv locks, which you
can't do from the fence signalling critical path.
2. drm_gpuvm_bo_put() calls drm_gem_object_put(), which is often going
to be unsafe to call from the fence signalling critical path.
To solve these issues, add a deferred version of drm_gpuvm_unlink() that
adds the vm_bo to a deferred cleanup list, and then clean it up later.
The new methods take the GEMs GPUVA lock internally rather than letting
the caller do it because it also needs to perform an operation after
releasing the mutex again. This is to prevent freeing the GEM while
holding the mutex (more info as comments in the patch). This means that
the new methods can only be used with DRM_GPUVM_IMMEDIATE_MODE.
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://lore.kernel.org/r/20251006-vmbo-defer-v4-1-30cbd2c05adb@google.com
[aliceryhl: fix formatting of vm_bo = llist_entry(...) line]
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Diffstat (limited to 'rust/kernel')
0 files changed, 0 insertions, 0 deletions
