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

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

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@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?

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx