From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wi0-f181.google.com ([209.85.212.181]:38509 "EHLO mail-wi0-f181.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751097AbbJWIE3 (ORCPT ); Fri, 23 Oct 2015 04:04:29 -0400 Received: by wicll6 with SMTP id ll6so20182165wic.1 for ; Fri, 23 Oct 2015 01:04:27 -0700 (PDT) Date: Fri, 23 Oct 2015 10:04:24 +0200 From: Daniel Vetter To: Kristian =?iso-8859-1?Q?H=F8gsberg?= Cc: Chris Wilson , "intel-gfx@lists.freedesktop.org" , Daniel Vetter , stable@vger.kernel.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: Deny wrapping an userptr into a framebuffer Message-ID: <20151023080424.GJ16848@phenom.ffwll.local> References: <1444742546-27401-1-git-send-email-chris@chris-wilson.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Sender: stable-owner@vger.kernel.org List-ID: On Thu, Oct 22, 2015 at 04:23:09PM -0700, Kristian H�gsberg wrote: > 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? I'd like to not add more complexity to a root-only feature. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch