From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io0-f173.google.com ([209.85.223.173]:35235 "EHLO mail-io0-f173.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752848AbbJWTUm convert rfc822-to-8bit (ORCPT ); Fri, 23 Oct 2015 15:20:42 -0400 Received: by iofz202 with SMTP id z202so133962307iof.2 for ; Fri, 23 Oct 2015 12:20:41 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20151023092805.GF2551@nuc-i3427.alporthouse.com> References: <1444742546-27401-1-git-send-email-chris@chris-wilson.co.uk> <20151023080424.GJ16848@phenom.ffwll.local> <20151023092805.GF2551@nuc-i3427.alporthouse.com> Date: Fri, 23 Oct 2015 12:20:41 -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 , Daniel Vetter , =?UTF-8?Q?Kristian_H=C3=B8gsberg?= , "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 Fri, Oct 23, 2015 at 2:28 AM, Chris Wilson wrote: > On Fri, Oct 23, 2015 at 10:04:24AM +0200, Daniel Vetter wrote: >> 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. > > I've considered dropping the root-only restriction. As we've spent more > time analysing what exactly happens if we miss the mmu-notification and > we've decided that it can't grant access to other pages, it just causes > the information on the GPU and on the CPU to become unsynchronized. In > some situations that can be problematic (such as when the surface is > pinned by the hardware and we cannot keep the contract of maintaining > sync with the client address range), but normally the error is just > consistent with failing to the SET_DOMAIN api correctly. On that scale > of things, it is not as large a shotgun as I first feared and we could > ease the restriction and allow it for all. (I still would say that > unsync should only be used for objects being allocated and under full > control by the driver, importing client memory should be extremely > cautious). > > We still have the requirement that surfaces exported between processes > use mmu-notifiers in order to revoke the exported surface when the > original mm is torndown, so it is not as simple to just allow fb on some > userptr and not others. (As we may still end up in the situation where > we need to revoke the pinned fb and fail miserably.) But that may just > be overthinking the issue, and letting the pages from one mm be pinned > onto the hw by another process and persist after the first is freed is > not an issue either. > > So yes, following the same chain of logic, we could allow unsync fb, but > first we need to relax a few other restrictions en route and then we can > just reject creating fb on userptr with mmu-notifiers attached. > -Chris Thanks, that all sounds good. Kristian > > -- > Chris Wilson, Intel Open Source Technology Centre