01.09.2022 17:02, Ruhl, Michael J пишет: ...
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c @@ -331,7 +331,19 @@ static void __i915_gem_free_objects(struct drm_i915_private *i915, continue; }
/** dma_buf_unmap_attachment() requires reservation to be* locked. The imported GEM shouldn't share reservation lock,* so it's safe to take the lock.*/if (obj->base.import_attach)i915_gem_object_lock(obj, NULL);There is a lot of stuff going here. Taking the lock may be premature...
__i915_gem_object_pages_fini(obj);The i915_gem_dmabuf.c:i915_gem_object_put_pages_dmabuf is where unmap_attachment is actually called, would it make more sense to make do the locking there?
The __i915_gem_object_put_pages() is invoked with a held reservation lock, while freeing object is a special time when we know that GEM is unused.
The __i915_gem_free_objects() was taking the lock two weeks ago until the change made Chris Wilson [1] reached linux-next.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?...
I don't think we can take the lock within i915_gem_object_put_pages_dmabuf(), it may/should deadlock other code paths.