From mboxrd@z Thu Jan 1 00:00:00 1970 From: Martin Peres Subject: Re: [RFC] Complete experimental render node implementation Date: Tue, 18 Dec 2012 13:23:51 +0100 Message-ID: <50D06057.3020004@free.fr> References: <50CE7868.4040205@free.fr> <20121218120305.GU5737@phenom.ffwll.local> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; Format="flowed" Content-Transfer-Encoding: quoted-printable Return-path: Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [212.27.42.4]) by gabe.freedesktop.org (Postfix) with ESMTP id 9B3AEE5E9B for ; Tue, 18 Dec 2012 04:24:06 -0800 (PST) In-Reply-To: <20121218120305.GU5737@phenom.ffwll.local> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Daniel Vetter Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org Le 18/12/2012 13:03, Daniel Vetter a =E9crit : > On Mon, Dec 17, 2012 at 02:42:00AM +0100, Martin Peres wrote: >> Hi, >> >> Following to my shared talk with krh, danvet and Timoth=E9e Ravier @ >> XDC2012, I have >> actually taken the time to start fixing some security holes found in >> the graphics stack. >> >> Today, I would like to request your comments on the render node >> patchset. Keep in mind that I am >> not asking for inclusion. However, I know this patchset works on my >> nvidia card and I would like >> to know if anyone has anything against this architecture. >> >> ## DRM >> If I'm not mistaken, the idea originated from airlied which got >> simplified later by krh. >> Both only provided drm patches. >> >> Here is what I did: >> - I took krh's patchset >> - rebased it on top on drm 3.7-rc8 >> - added support for Nouveau >> - fixed a few bugs along the way (as stated in the commit logs) >> >> The kernel can be found here: https://gitorious.org/linux-nouveau-pm/lin= ux-nouveau-pm/commits/render_nodes >> The patches will also be sent in reply, to let you comment on >> specific parts of the patches. > One thing which stalled this on the kernel side, and I think we really > need this before it's useful, is per-open-file mmap spaces. Otherwise > everyone can still read back your textures easily ... Yeah, krh told me about it. It was on this week's todo list but it may = be pushed back to this week end. > I've looked around a bit, and besides the plumbing to set up per-open-file > mmap offset infrastructure it shouldn't be hard, the linux mm already > passes in the file pointer to the ->mmap driver callback. One thing though > is to clean up things a bit maybe - iirc ttm based drivers use their own > lookup cache for mmap offset, and there's still the legacy drm map support > which really shouldn't be exposed to rendernodes. I have this on my todo > somewhere, but at the current rate&backlog it'll take a while for me to > get around to this, so maybe I can volunteer you? Sure! When I sent the mail, I realized I forgot to talk about my DRM = todo list. This was the number one issue I had. Thanks for the suggestions, I will look into it promptly. > Also I think we need this implemented just in case some aweful userspace > breaks due to the per-file mmap space (there's been some decently aweful > code in intel-land ...). So, you mean some intel-oriented sw communicate the mapping offset = between each others? That's ugly as hell! > I can't really comment on the other pieces of this due to lack of > knowledge. Thanks, I do not expect for every one to have some feedback on the whole = patchset. I'm new to these user-space projects too... > > Cheers, Daniel Thanks for taking the time to answer me! Cheers, Martin