Quoting Maarten Lankhorst (2020-01-31 10:12:36) > Op 30-01-2020 om 12:58 schreef Chris Wilson: > > On seqno rollover, we need to allocate ourselves a new cacheline. This > > might incur grabbing a new page and pinning it into the GGTT, with some > > rather unfortunate lockdep implications. > > > > To avoid a mutex, and more specifically pinning in the GGTT from inside > > the kernel context being used to flush the GGTT in emergencies, we will > > likely need to lift the next-cacheline allocation to a pre-reservation. > > > > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > > Cc: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > --- > > drivers/gpu/drm/i915/gt/intel_timeline.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c b/drivers/gpu/drm/i915/gt/intel_timeline.c > > index 465f87b65901..54e1e55f3c81 100644 > > --- a/drivers/gpu/drm/i915/gt/intel_timeline.c > > +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c > > @@ -406,6 +406,8 @@ __intel_timeline_get_seqno(struct intel_timeline *tl, > > void *vaddr; > > int err; > > > > + might_lock(&tl->gt->ggtt->vm.mutex); > > + > > /* > > * If there is an outstanding GPU reference to this cacheline, > > * such as it being sampled by a HW semaphore on another timeline, > > Reviewed-by: Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxxxx> > > If this breaks on lockdep, it was already broken. I have to write a selftest to cause seqno wrap on the kernel_context to readily demonstrate the breakage. :| -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
