Having spent some time with DBG_FORCE_RELOC == FORCE_CPU_RELOC, it
appears that our memory barriers around the clflush are lackluster for
our more seldom used paths. Seldom used does not mean never, so apply
the memory barriers or else we may randomly see incorrect relocation
addresses inside batches.
Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx>
Cc: stable@xxxxxxxxxxxxxxx
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 230ba1aee355..d9ab517bbce9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1037,6 +1037,8 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
void *vaddr;
if (cache->vaddr) {
+ if (cache->vaddr & CLFLUSH_AFTER)
+ mb();
kunmap_atomic(unmask_page(cache->vaddr));
} else {
unsigned int flushes;
@@ -1051,14 +1053,15 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
cache->vaddr = flushes | KMAP;
cache->node.mm = (void *)obj;
- if (flushes)
- mb();
}
vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj, page));
cache->vaddr = unmask_flags(cache->vaddr) | (unsigned long)vaddr;
cache->page = page;
+ if (cache->vaddr & CLFLUSH_BEFORE)
+ mb();
+
return vaddr;
}
@@ -1163,8 +1166,10 @@ static void clflush_write32(u32 *addr, u32 value, unsigned int flushes)
* mb barriers at the start and end of the relocation phase
* to ensure ordering of clflush wrt to the system.
*/
- if (flushes & CLFLUSH_AFTER)
+ if (flushes & CLFLUSH_AFTER) {
+ mb();
clflushopt(addr);
+ }
} else
*addr = value;
}
--
2.20.1
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
