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/?id=2826d447fbd60e6a05e53d5f918bceb8c04e315c I don't think we can take the lock within i915_gem_object_put_pages_dmabuf(), it may/should deadlock other code paths.
