]> git.baikalelectronics.ru Git - kernel.git/commit
drm/i915: Ensure consistent control flow __i915_gem_active_get_rcu
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Mon, 22 Aug 2016 08:55:22 +0000 (10:55 +0200)
committerChris Wilson <chris@chris-wilson.co.uk>
Mon, 22 Aug 2016 10:15:09 +0000 (11:15 +0100)
commit0a857fc8adb9e5c43309c138ca61b765e40cdb3e
tree19b8b379b9ff28be1f21f1d70afd84ed61d28ba4
parent92d0b44872710c7a7ca893a0bb2cf5fc0f7d985f
drm/i915: Ensure consistent control flow __i915_gem_active_get_rcu

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@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: http://patchwork.freedesktop.org/patch/msgid/1471856122-466-1-git-send-email-daniel.vetter@ffwll.ch
drivers/gpu/drm/i915/i915_gem_request.h