[Intel-gfx] [PATCH] drm/i915: Move the mb() following release-mmap into release-mmap
Tvrtko Ursulin
tvrtko.ursulin at linux.intel.com
Tue Oct 6 07:40:02 PDT 2015
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?
Regards,
Tvrtko
More information about the Intel-gfx
mailing list