From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f172.google.com ([209.85.213.172]:38533 "EHLO mail-ig0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755457AbbJVXXK convert rfc822-to-8bit (ORCPT ); Thu, 22 Oct 2015 19:23:10 -0400 Received: by igbdj2 with SMTP id dj2so5243514igb.1 for ; Thu, 22 Oct 2015 16:23:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <1444742546-27401-1-git-send-email-chris@chris-wilson.co.uk> References: <1444742546-27401-1-git-send-email-chris@chris-wilson.co.uk> Date: Thu, 22 Oct 2015 16:23:09 -0700 Message-ID: Subject: Re: [Intel-gfx] [PATCH] drm/i915: Deny wrapping an userptr into a framebuffer From: =?UTF-8?Q?Kristian_H=C3=B8gsberg?= To: Chris Wilson Cc: "intel-gfx@lists.freedesktop.org" , Daniel Vetter , stable@vger.kernel.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: stable-owner@vger.kernel.org List-ID: On Tue, Oct 13, 2015 at 6:22 AM, Chris Wilson 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 > Cc: Daniel Vetter > Cc: Tvrtko Ursulin > Cc: Michał Winiarski > Cc: stable@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@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx