[Intel-gfx] [PATCH] drm/i915: Ensure consistent control flow __i915_gem_active_get_rcu

Chris Wilson chris at chris-wilson.co.uk
Mon Aug 22 10:15:55 UTC 2016


On Mon, Aug 22, 2016 at 10:55:22AM +0200, Daniel Vetter wrote:
> This issue here is (I think) purely theoretical, since a compiler
> would need to be especially foolish to recompute the value of
> i915_gem_request_completed right after it was already used. Hence the
> additional barrier() is also not really a restriction.
> 
> But I believe this to be at least permissible, and since our rcu
> trickery is a beast it's worth to annotate all the corner cases.
> Chris proposed to instead just wrap a READ_ONCE around
> request->fence.seqno in i915_gem_request_completed. But that has a
> measurable impact on code size, and everywhere we hold a full
> reference to the underlying request it's also not needed. And
> personally I'd like to have just enough barriers and locking needed
> for correctness, but not more - it makes it much easier in the future
> to understand what's going on.
> 
> Since the busy ioctl has now fully embraced it's races there's no
> point annotating it there too. We really only need it in
> active_get_rcu, since that function _must_ deliver a correct snapshot
> of the active fences (and not chase something else).
> 
> v2: Polish the comment a bit more (Chris).
> 
> Cc: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> Reviewed-by: Chris Wilson <chris at chris-wilson.co.uk>
> Signed-off-by: Daniel Vetter <daniel.vetter at intel.com>

Just the fun of the role reversal, I've pushed it.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the Intel-gfx mailing list