From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com ([192.55.52.115]:42533 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932344AbbJMOAU (ORCPT ); Tue, 13 Oct 2015 10:00:20 -0400 Subject: Re: [Intel-gfx] [PATCH] drm/i915: Deny wrapping an userptr into a framebuffer To: Chris Wilson , intel-gfx@lists.freedesktop.org References: <1444742546-27401-1-git-send-email-chris@chris-wilson.co.uk> Cc: Daniel Vetter , stable@vger.kernel.org From: Tvrtko Ursulin Message-ID: <561D0E72.9060507@linux.intel.com> Date: Tue, 13 Oct 2015 15:00:18 +0100 MIME-Version: 1.0 In-Reply-To: <1444742546-27401-1-git-send-email-chris@chris-wilson.co.uk> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: stable-owner@vger.kernel.org List-ID: On 13/10/15 14:22, 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. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko