| Message ID | 20191106154810.5843-1-chris@chris-wilson.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/3] drm/i915: Handle i915_active_fence_set() with the same fence | expand |
On 06/11/2019 15:48, Chris Wilson wrote: > If the caller wants to overwrite the currently tracked fence, with > itself, as far as the tracking is concerned it is a no-op, so simply > allow it. This is needed for some of the following patches in this series? Regards, Tvrtko > Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> > Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> > --- > drivers/gpu/drm/i915/i915_active.c | 5 ++++- > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c > index 207383dda84d..cde984744f20 100644 > --- a/drivers/gpu/drm/i915/i915_active.c > +++ b/drivers/gpu/drm/i915/i915_active.c > @@ -759,7 +759,9 @@ __i915_active_fence_set(struct i915_active_fence *active, > > prev = rcu_dereference_protected(active->fence, active_is_held(active)); > if (prev) { > - GEM_BUG_ON(prev == fence); > + if (unlikely(prev == fence)) > + goto unlock; > + > spin_lock_nested(prev->lock, SINGLE_DEPTH_NESTING); > __list_del_entry(&active->cb.node); > spin_unlock(prev->lock); /* serialise with prev->cb_list */ > @@ -781,6 +783,7 @@ __i915_active_fence_set(struct i915_active_fence *active, > rcu_assign_pointer(active->fence, fence); > list_add_tail(&active->cb.node, &fence->cb_list); > > +unlock: > spin_unlock_irqrestore(fence->lock, flags); > > return prev; >
Quoting Tvrtko Ursulin (2019-11-08 10:37:37) > > On 06/11/2019 15:48, Chris Wilson wrote: > > If the caller wants to overwrite the currently tracked fence, with > > itself, as far as the tracking is concerned it is a no-op, so simply > > allow it. > > This is needed for some of the following patches in this series? The implementation is relaxed in patch 3, which means we allow the user to update the same i915_request.fence on the same timeline multiple times. We already allow them to use the same fence multiple times, symmetry is good?... -Chris
diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c index 207383dda84d..cde984744f20 100644 --- a/drivers/gpu/drm/i915/i915_active.c +++ b/drivers/gpu/drm/i915/i915_active.c @@ -759,7 +759,9 @@ __i915_active_fence_set(struct i915_active_fence *active, prev = rcu_dereference_protected(active->fence, active_is_held(active)); if (prev) { - GEM_BUG_ON(prev == fence); + if (unlikely(prev == fence)) + goto unlock; + spin_lock_nested(prev->lock, SINGLE_DEPTH_NESTING); __list_del_entry(&active->cb.node); spin_unlock(prev->lock); /* serialise with prev->cb_list */ @@ -781,6 +783,7 @@ __i915_active_fence_set(struct i915_active_fence *active, rcu_assign_pointer(active->fence, fence); list_add_tail(&active->cb.node, &fence->cb_list); +unlock: spin_unlock_irqrestore(fence->lock, flags); return prev;
If the caller wants to overwrite the currently tracked fence, with itself, as far as the tracking is concerned it is a no-op, so simply allow it. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> --- drivers/gpu/drm/i915/i915_active.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-)