Quoting Tvrtko Ursulin (2019-09-25 14:01:51) > > On 25/09/2019 13:53, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2019-09-25 13:43:46) > >> > >> On 25/09/2019 11:01, Chris Wilson wrote: > >>> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c b/drivers/gpu/drm/i915/gt/intel_reset.c > >>> index 2685c0103e90..ee0c5c24282c 100644 > >>> --- a/drivers/gpu/drm/i915/gt/intel_reset.c > >>> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c > >>> @@ -1265,10 +1265,6 @@ int intel_gt_terminally_wedged(struct intel_gt *gt) > >>> if (!test_bit(I915_RESET_BACKOFF, >->reset.flags)) > >>> return -EIO; > >>> > >>> - /* XXX intel_reset_finish() still takes struct_mutex!!! */ > >>> - if (mutex_is_locked(>->i915->drm.struct_mutex)) > >>> - return -EAGAIN; > >>> - > >> > >> What is this hunk doing here? > > > > Because the overlay used struct_mutex, now it does not. > > Now you see why I insist on comments and even better if they are up to > date! :) (intel_reset_finish?!) In this case, the last remaining use was actually intel_reset_prepare, as we have to disable the overlay before doing a GPU reset. It's just that we could have mitigated the prepare, but had been stymied by the intel_reset_finish struct_mutex recursion. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
