[Intel-gfx] [PATCH] drm/i915: Deny wrapping an userptr into a framebuffer

[Kristian Høgsberg]

On Tue, Oct 13, 2015 at 6:22 AM, Chris Wilson <chris at chris-wilson.co.uk> wrote:
> Pinning a userptr onto the hardware raises interesting questions about
> the lifetime of such a surface as the framebuffer extends that life
> beyond the client's address space. That is the hardware will need to
> keep scanning out from the backing storage even after the client wants
> to remap its address space. As the hardware pins the backing storage,
> the userptr becomes invalid and this raises a WARN when the clients
> tries to unmap its address space. The situation can be even more
> complicated when the buffer is passed between processes, between a
> client and display server, where the lifetime and hardware access is
> even more confusing. Deny it.

Can we allow this for unsynchronized userptrs?

Kristian

> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> Cc: Michał Winiarski <michal.winiarski at intel.com>
> Cc: stable at vger.kernel.org
> ---
>  drivers/gpu/drm/i915/i915_gem_userptr.c | 5 ++++-
>  drivers/gpu/drm/i915/intel_display.c    | 5 +++++
>  2 files changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_userptr.c b/drivers/gpu/drm/i915/i915_gem_userptr.c
> index 2dd911ab3019..3ce1b557f7c4 100644
> --- a/drivers/gpu/drm/i915/i915_gem_userptr.c
> +++ b/drivers/gpu/drm/i915/i915_gem_userptr.c
> @@ -974,7 +974,10 @@ out:
>   * Also note, that the object created here is not currently a "first class"
>   * object, in that several ioctls are banned. These are the CPU access
>   * ioctls: mmap(), pwrite and pread. In practice, you are expected to use
> - * direct access via your pointer rather than use those ioctls.
> + * direct access via your pointer rather than use those ioctls. Another
> + * restriction is that we do not allow userptr surfaces to be pinned to the
> + * hardware and so we reject any attempt to create a framebuffer out of a
> + * userptr.
>   *
>   * If you think this is a good interface to use to pass GPU memory between
>   * drivers, please use dma-buf instead. In fact, wherever possible use
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index b89131654a0e..d1deaedcc4ce 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14116,6 +14116,11 @@ static int intel_user_framebuffer_create_handle(struct drm_framebuffer *fb,
>         struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
>         struct drm_i915_gem_object *obj = intel_fb->obj;
>
> +       if (obj->userptr.mm) {
> +               DRM_DEBUG("attempting to use a userptr for a framebuffer, denied\n");
> +               return -EINVAL;
> +       }
> +
>         return drm_gem_handle_create(file, &obj->base, handle);
>  }
>
> --
> 2.6.1
>
> _______________________________________________
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx