All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin Peres <martin.peres@free.fr>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: dri-devel@lists.freedesktop.org
Subject: Re: [RFC] Complete experimental render node implementation
Date: Tue, 18 Dec 2012 13:23:51 +0100	[thread overview]
Message-ID: <50D06057.3020004@free.fr> (raw)
In-Reply-To: <20121218120305.GU5737@phenom.ffwll.local>

Le 18/12/2012 13:03, Daniel Vetter a écrit :
> On Mon, Dec 17, 2012 at 02:42:00AM +0100, Martin Peres wrote:
>> Hi,
>>
>> Following to my shared talk with krh, danvet and Timothée 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/linux-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

  reply	other threads:[~2012-12-18 12:24 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-17  1:42 [RFC] Complete experimental render node implementation Martin Peres
2012-12-17  1:47 ` [PATCH 1/4] drm: Fix DRM_MINOR limits for control and render nodes martin.peres
2012-12-17  1:48   ` [PATCH 2/4] drm: Add support for " martin.peres
2012-12-17  1:48   ` [PATCH 3/4] drm/i915: Support " martin.peres
2012-12-17  1:48   ` [PATCH 4/4] drm/nouveau: " martin.peres
2012-12-17  2:02 ` [PATCH 1/5] drm: allow opening the drm device by type (control, render or render_only) martin.peres
2012-12-17  2:02   ` [PATCH 2/5] drm: generate the path of a different device type for the same drm device martin.peres
2012-12-17  2:02   ` [PATCH 3/5] nouveau: Allow opening a specific type of " martin.peres
2012-12-17  2:02   ` [PATCH 4/5] nouveau: bump version to 2.4.34 for release martin.peres
2012-12-17  2:02   ` [PATCH 5/5] configure.ac: bump version to 2.4.41 " martin.peres
2012-12-17  2:06 ` [PATCH] dri2proto: add device_requires_auth in xDRI2ConnectReply to support render nodes martin.peres
2012-12-17  2:09 ` [PATCH] dri2: add support for " martin.peres
2012-12-17  2:10 ` [PATCH] " martin.peres
2012-12-17  2:13 ` [PATCH] dri2: " martin.peres
2012-12-18 12:03 ` [RFC] Complete experimental render node implementation Daniel Vetter
2012-12-18 12:23   ` Martin Peres [this message]
  -- strict thread matches above, loose matches on Subject: below --
2012-12-17  1:39 Martin Peres

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50D06057.3020004@free.fr \
    --to=martin.peres@free.fr \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.