Since the advent of mmap(wc), where we reused the same cache domain for
WC and GTT paths (oh, how I regret that double-edged advice), we need to
be extra cautious when using GTT iomap_wc internally. Since userspace maybe
modifying through the mmap(wc) and we then modify modifying through an
aliased WC path through the GTT, those writes may overlap and not be
visible to the other path. Easiest to trigger appears to be write the
batch through mmap(wc) and then attempt to perform reloc the GTT,
corruption quickly ensues.
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: Akash Goel <akash.goel@xxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
---
drivers/gpu/drm/i915/i915_gem.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 517c5b8100d1..5f2bb1f92879 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3922,8 +3922,17 @@ i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj, bool write)
struct i915_vma *vma;
int ret;
- if (obj->base.write_domain == I915_GEM_DOMAIN_GTT)
+ if (obj->base.write_domain == I915_GEM_DOMAIN_GTT) {
+ /*
+ * Userspace may be writing through mmap(wc) with
+ * write_domain=GTT, so we need to explicitly flush before
+ * transitioning to writing through the GTT, or vice versa.
+ * As we reused the cache domain for both paths, we must
+ * always have a write barrier just in case.
+ */
+ wmb();
return 0;
+ }
ret = i915_gem_object_wait_rendering(obj, !write);
if (ret)
--
2.1.4
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
