Quoting Matthew Auld (2020-03-23 11:38:09)
> 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.
Hmm. Sounds a fair point, though let's see if that is not an unintended
bonus.
> 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.
However that is a bug we have to handle. And it should be prevented
currently by avoiding shrinking active (still being bound) vma, e.g.
6f24e41022f2 ("drm/i915: Avoid recursing onto active vma from the
shrinker"). So is that a current observation?
-Chris
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
