On 31/05/2018 19:51, Chris Wilson wrote:
In the following patch, we will process the CSB interrupt under the
timeline.lock and not under the tasklet lock. This also means that we
Implied tasklet lock? Or tasklet serialization?
will need to protect access to common variables such as
execlists->csb_head with the timeline.lock during reset.
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
---
drivers/gpu/drm/i915/intel_lrc.c | 7 ++-----
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d207a1bf9dc9..ec54c29b610f 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1927,8 +1927,7 @@ static void execlists_reset(struct intel_engine_cs *engine,
engine->name, request ? request->global_seqno : 0,
intel_engine_get_seqno(engine));
- /* See execlists_cancel_requests() for the irq/spinlock split. */
- local_irq_save(flags);
+ spin_lock_irqsave(&engine->timeline.lock, flags);
/*
* Catch up with any missed context-switch interrupts.
@@ -1943,14 +1942,12 @@ static void execlists_reset(struct intel_engine_cs *engine,
reset_irq(engine);
There is a synchronize_hardirq in this one so this could be a deadlock I
think depending on lock ordering. If another CPU enters the irq handler
and tries to take the timeline lock which this thread already has, then
they deadlock each other.
Regards,
Tvrtko
/* Push back any incomplete requests for replay after the reset. */
- spin_lock(&engine->timeline.lock);
__unwind_incomplete_requests(engine);
- spin_unlock(&engine->timeline.lock);
/* Following the reset, we need to reload the CSB read/write pointers */
engine->execlists.csb_head = GEN8_CSB_ENTRIES - 1;
- local_irq_restore(flags);
+ spin_unlock_irqrestore(&engine->timeline.lock, flags);
/*
* If the request was innocent, we leave the request in the ELSP
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
