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);
|
||||
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! */
|
||||
__set_bit(I915_WEDGED, >->reset.flags);
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue