All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jerome Glisse <j.glisse@gmail.com>
To: Ilia Mirkin <imirkin@alum.mit.edu>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	Thomas Hellstrom <thellstrom@vmware.com>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH v2] drm: enable render-nodes by default
Date: Thu, 20 Mar 2014 11:35:47 -0400	[thread overview]
Message-ID: <20140320153545.GC2020@gmail.com> (raw)
In-Reply-To: <CAKb7UvikD8P8yh5+=o1MY35TyUw4Km+VpAWWwt=uuMFJEJMZgQ@mail.gmail.com>

On Thu, Mar 20, 2014 at 10:44:10AM -0400, Ilia Mirkin wrote:
> On Thu, Mar 20, 2014 at 10:36 AM, Jerome Glisse <j.glisse@gmail.com> wrote:
> > On Thu, Mar 20, 2014 at 11:28:18AM +0100, Thomas Hellstrom wrote:
> >> On 03/20/2014 10:43 AM, David Herrmann wrote:
> >> > On Thu, Mar 20, 2014 at 10:27 AM, Thomas Hellstrom
> >> > <thellstrom@vmware.com> wrote:
> >> > Given that the legacy node is always around and _always_ has these
> >> > races, why should we prevent render-nodes from appearing just because
> >> > the _driver_ is racy? I mean, there is no gain in that.. if it opens a
> >> > new race, as you assumed, then yes, we should avoid it. But at least
> >> > for all drivers supporting render-nodes so far, they either are
> >> > entirely safe or the just described races exist on both nodes.
> >>
> >> My suggestion is actually not to prevent render nodes from appearing,
> >> but rather that we should restrict them to drivers with command stream
> >> verification and / or per process virtual memory, and I also think we
> >> should plug the above races on legacy nodes. That way legacy nodes would
> >> use the old "master owns it all" model, while render nodes could allow
> >> multiple users at the same time.
> >
> > FYI both radeon and nouveau (last time i check) can not be abuse to access
> > random VRAM or buffer bind by another process (except if the buffer is share
> > of course).
> 
> I'm not aware of any restrictions in nouveau that would prevent you
> from accessing any vram... there are a number of copy engines
> accessible that would allow you to copy one region to another, and I'm
> not aware of code to validate pushbuf contents (it would have to parse
> the pushbuf and know which methods store source/destination
> addresses). You could probably get creative and use that to overwrite
> the MMU tables, to then gain the ability to read/write any part of
> system memory... but perhaps the engines won't allow you to do that,
> not sure. (Or perhaps the PDE isn't mapped into VRAM. Again, not
> sure.)
> 
>   -ilia

Well i obviously have not look at that in long time, but if the nouveau
API can be abuse than i consider this a broken by design. I know command
checking is painfull and CPU intensive but we have done it in radeon for
a reason.

Cheers,
Jérôme

  reply	other threads:[~2014-03-20 15:35 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-16 13:43 [PATCH] drm: enable render-nodes by default David Herrmann
2014-03-16 13:43 ` David Herrmann
2014-03-17 10:07 ` Daniel Vetter
2014-03-17 10:07   ` Daniel Vetter
2014-03-17 16:43 ` [PATCH v2] " David Herrmann
2014-03-20  6:43   ` Thomas Hellstrom
2014-03-20  7:36     ` David Herrmann
2014-03-20  8:48       ` Thomas Hellstrom
2014-03-20  9:05         ` David Herrmann
2014-03-20  9:27           ` Thomas Hellstrom
2014-03-20  9:43             ` David Herrmann
2014-03-20 10:28               ` Thomas Hellstrom
2014-03-20 14:36                 ` Jerome Glisse
2014-03-20 14:44                   ` Ilia Mirkin
2014-03-20 15:35                     ` Jerome Glisse [this message]
2014-03-20 17:39                     ` Ilia Mirkin
2014-03-20 14:59                   ` Thomas Hellstrom
2014-03-20 15:34                     ` Jerome Glisse
2014-03-20 15:49                       ` Thomas Hellstrom
2014-03-20 17:04                         ` Jerome Glisse
2014-03-20 17:34                 ` Rob Clark
2014-03-20 20:54                   ` Thomas Hellstrom
2014-03-20 21:13                     ` Rob Clark
2014-03-21  7:10                       ` Daniel Vetter
2014-03-21  8:29                         ` Thomas Hellstrom

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=20140320153545.GC2020@gmail.com \
    --to=j.glisse@gmail.com \
    --cc=daniel.vetter@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=imirkin@alum.mit.edu \
    --cc=thellstrom@vmware.com \
    /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.