Quoting Chris Wilson (2019-10-14 10:28:53) > Quoting Chris Wilson (2019-10-14 10:27:59) > > Quoting Tvrtko Ursulin (2019-10-14 10:25:04) > > > > > > On 13/10/2019 20:31, Chris Wilson wrote: > > > > We rely on only the tasklet being allowed to call into process_csb(), so > > > > assert that is locked when we do. As the tasklet uses a simple bitlock, > > > > there is no strong lockdep checking so we must make do with a plain > > > > assertion that the tasklet is running and assume that we are the > > > > tasklet! > > > > > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > > > Cc: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx> > > > > --- > > > > drivers/gpu/drm/i915/gt/intel_lrc.c | 1 + > > > > drivers/gpu/drm/i915/i915_gem.h | 5 +++++ > > > > 2 files changed, 6 insertions(+) > > > > > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c b/drivers/gpu/drm/i915/gt/intel_lrc.c > > > > index 8be9e69d5718..ab20433182d1 100644 > > > > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > > > > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > > > > @@ -1984,6 +1984,7 @@ static void process_csb(struct intel_engine_cs *engine) > > > > u8 head, tail; > > > > > > > > GEM_BUG_ON(USES_GUC_SUBMISSION(engine->i915)); > > > > + GEM_BUG_ON(!tasklet_is_locked(&execlists->tasklet)); > > > > > > I see some reset paths calling process_csb which looks like a problem > > > for this assert. > > > > Oh, no it's not :) > > > > execlists_reset() is surrounded by reset_prepare and reset_finish who > > are responsible for disabling the tasklet and serialising with direct > > submission around the reset. > > Same being true for cancel_requests, on wedging we have to disable the > tasklet before taking control of the state. Hmm. That being said we do have that sanitize path which cuts a few corners. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
