[RFC PATCH] drm/i915: Never return active fence as previous last active

[Janusz Krzysztofik]

After updating the last active fence along its timeline, we expect to get
back a reference to a fence that was the last active one before the
update, or NULL if there was none.  As a third possibility, we can
theoretically get a reference to the new fence if it was already in place
and have been left intact.

Never observed in practice while exercising the driver, that hypothetical
case however seems more equivalent to the case when the timeline with no
active fence is updated with our new fence and NULL rather than a
reference to a previously active fence is returned.  If users don't
distinguish between the return value pointing to the new fence vs the
previously active one before processing it, results may be different than
expected, I believe.

Return NULL if the new fence is found already active (this approach seems
better to me than fixing the potential issue on user side).  Also, trigger
a warning if that happens so we are notified if there are any problematic
use cases that can require more attention and maybe a different solution.

Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik at linux.intel.com>
---
 drivers/gpu/drm/i915/i915_active.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_active.c b/drivers/gpu/drm/i915/i915_active.c
index 7412abf166a8c..644e8fcf27e7b 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -1029,8 +1029,8 @@ __i915_active_fence_set(struct i915_active_fence *active,
 	struct dma_fence *prev;
 	unsigned long flags;
 
-	if (fence == rcu_access_pointer(active->fence))
-		return fence;
+	if (GEM_WARN_ON(fence == rcu_access_pointer(active->fence)))
+		return NULL;
 
 	GEM_BUG_ON(test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->flags));
 
-- 
2.25.1