[Intel-gfx] [PATCH] drm/i915: Move the mb() following release-mmap into release-mmap

[Chris Wilson]

On Tue, Oct 06, 2015 at 03:40:02PM +0100, Tvrtko Ursulin wrote:
> 
> 
> Hi,
> 
> On 06/10/15 12:58, Chris Wilson wrote:
> >As paranoia, we want to ensure that the CPU's PTEs have been revoked for
> >the object before we return from i915_gem_release_mmap(). This allows us
> >to rely on there being no outstanding memory accesses and guarantees
> >serialisation of the code against concurrent access just by calling
> >i915_gem_release_mmap().
> >
> >Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> >---
> >  drivers/gpu/drm/i915/i915_gem.c | 13 ++++++++++---
> >  1 file changed, 10 insertions(+), 3 deletions(-)
> >
> >diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> >index 2b8ed7a2faab..642644f12295 100644
> >--- a/drivers/gpu/drm/i915/i915_gem.c
> >+++ b/drivers/gpu/drm/i915/i915_gem.c
> >@@ -1877,11 +1877,21 @@ out:
> >  void
> >  i915_gem_release_mmap(struct drm_i915_gem_object *obj)
> >  {
> >+	/* Serialisation between user GTT access and our code depends upon
> >+	 * revoking the CPU's PTE whilst the mutex is held. The next user
> >+	 * pagefault then has to wait until we release the mutex.
> >+	 */
> >+	lockdep_assert_held(&obj->base.dev->struct_mutex);
> >+
> >  	if (!obj->fault_mappable)
> >  		return;
> >
> >  	drm_vma_node_unmap(&obj->base.vma_node,
> >  			   obj->base.dev->anon_inode->i_mapping);
> >+
> >+	/* Ensure that the CPU's PTE are revoked before we return */
> >+	mb();
> >+
> 
> smp_mb() or smp_wmb() would not suffice? Is it needed on uniprocessor?

Correct, smp_mb() would not suffice as we are serialised accessing
through a mmio channel with the PTE writes.

A wmb() may suffice though, but that actually changed code :)
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre