drm/i915/gt: Taint the reset mutex with the shrinker
Declare that, under extreme circumstances, the shrinker may need to wait upon a request, in which case reset must not itself deadlock in order to ensure forward progress of the driver. That is since the shrinker may depend upon a reset, any reset cannot touch the shrinker. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20201229141626.4773-1-chris@chris-wilson.co.uk
This commit is contained in:
parent
cc1557cadf
commit
cecb2af42c
|
@ -1394,6 +1394,17 @@ void intel_gt_init_reset(struct intel_gt *gt)
|
||||||
mutex_init(>->reset.mutex);
|
mutex_init(>->reset.mutex);
|
||||||
init_srcu_struct(>->reset.backoff_srcu);
|
init_srcu_struct(>->reset.backoff_srcu);
|
||||||
|
|
||||||
|
/*
|
||||||
|
* While undesirable to wait inside the shrinker, complain anyway.
|
||||||
|
*
|
||||||
|
* If we have to wait during shrinking, we guarantee forward progress
|
||||||
|
* by forcing the reset. Therefore during the reset we must not
|
||||||
|
* re-enter the shrinker. By declaring that we take the reset mutex
|
||||||
|
* within the shrinker, we forbid ourselves from performing any
|
||||||
|
* fs-reclaim or taking related locks during reset.
|
||||||
|
*/
|
||||||
|
i915_gem_shrinker_taints_mutex(gt->i915, >->reset.mutex);
|
||||||
|
|
||||||
/* no GPU until we are ready! */
|
/* no GPU until we are ready! */
|
||||||
__set_bit(I915_WEDGED, >->reset.flags);
|
__set_bit(I915_WEDGED, >->reset.flags);
|
||||||
}
|
}
|
||||||
|
|
Loading…
Reference in New Issue