The subtest shrink_boom was added as a regression test for some missing refcounting on the paging structures, however since the binding is potentially async, setting the vm->fault_attr might apply to the purge vma, and not the intended explode vma. Also it looks like it might also be possible to hit some weird shrinker deadlock where the unbinding of one vma allocates memory by flushing and waiting for its still-pending-bind operation while holding vm->mutex, which will always lands back in the shrinker since we set vm->fault_attr for the selftest. References: https://gitlab.freedesktop.org/drm/intel/issues/1493 Signed-off-by: Matthew Auld <matthew.auld@xxxxxxxxx> --- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index b342bef5e7c9..029406a2a0b3 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -951,6 +951,8 @@ static int shrink_boom(struct i915_address_space *vm, if (err) goto err_purge; + i915_vma_sync(vma); + /* Should now be ripe for purging */ i915_vma_unpin(vma); @@ -974,6 +976,8 @@ static int shrink_boom(struct i915_address_space *vm, if (err) goto err_explode; + i915_vma_sync(vma); + i915_vma_unpin(vma); i915_gem_object_put(purge); -- 2.20.1 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
