Re: [PATCH 04/22] drm/i915: Hold a ref to the ring while retiring

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On 18/03/2019 10:37, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-03-18 10:31:57)

On 18/03/2019 09:51, Chris Wilson wrote:
As the final request on a ring may hold the reference to this ring (via
retiring the last pinned context), we may find ourselves chasing a
dangling pointer on completion of the list.

A quick solution is to hold a reference to the ring itself as we retire
along it so that we only free it after we stop dereferencing it.

Is there a guilty commit to reference as Fixes: ?

It only becomes a problem with veng as we gain an immediate free path,
whereas at the moment, context frees are deferred until they can acquire
the struct_mutex. We cannot hit this path at the moment, but that we had
to use the safe iterator implies that we were aware that the ring itself
could disappear. If you wanted to pin it on something,

References: b887d6154624 ("drm/i915: Retire requests along rings")

Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
---
   drivers/gpu/drm/i915/i915_request.c          |  6 +++++-
   drivers/gpu/drm/i915/intel_engine_types.h    |  2 ++
   drivers/gpu/drm/i915/intel_lrc.c             |  4 ++--
   drivers/gpu/drm/i915/intel_ringbuffer.c      |  9 +++++----
   drivers/gpu/drm/i915/intel_ringbuffer.h      | 13 ++++++++++++-
   drivers/gpu/drm/i915/selftests/mock_engine.c |  1 +
   6 files changed, 27 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
index 9533a85cb0b3..0a3d94517d0a 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1332,8 +1332,12 @@ void i915_retire_requests(struct drm_i915_private *i915)
       if (!i915->gt.active_requests)
               return;
- list_for_each_entry_safe(ring, tmp, &i915->gt.active_rings, active_link)
+     list_for_each_entry_safe(ring, tmp,
+                              &i915->gt.active_rings, active_link) {
+             intel_ring_get(ring); /* last rq holds reference! */
               ring_retire_requests(ring);
+             intel_ring_put(ring);
+     }

Where does it chase a dangling pointer? It used the safe iterator already.

Inside ring_retire_requests(); the use of _safe here actually implies we
met this problem already :)

I get it, the issue is during ring->request_list iteration in ring_retire_requests. How about move ring pinning in there so it is clearer?

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx




[Index of Archives]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux